Enabling Automatic Bug Expiry
I recently sent out an email to Launchpad users who had selected the “expire incomplete bug reports” option for their project, explaining that we would be enabling this feature again in Launchpad. Well, actually, I sent out a lot of emails. This happened partly due to poor design of the script I wrote to send the emails and partly due to my own error. I am sorry for the inconvenience this may have caused anyone. We are taking steps to ensure this sort of poorly executed mass emailing doesn’t happen again on Launchpad.
For those who haven’t heard, the rest of this blog post is meant to fill you in on the coming changes.
What is about to change?
Launchpad has always advertised that we auto-expire incomplete bugs matching certain conditions, but we haven’t done this for awhile now. We are ready to turn this feature back on. This means that bugs that are considered inactive will have their status automatically changed from Incomplete to Expired. For more detail on how Launchpad determines if a bug is inactive, visit our Bug Expiry help page.
This change will take effect in about two weeks, sometime during the week of 18 October 2010.
What this means to you?
If you maintain a project in Launchpad and you want this feature, you need to ensure that the Expire “Incomplete” bug reports when they become inactive option is selected for your project on it’s Configure bug tracker page. We have disabled it for all projects since it has been selected by default but inactive up until now. Sometime before the week of 18 October, you’ll need to re-enable this option if you want to take advantage of automatic bug expiry.
If you maintain a project in Launchpad and you do not want this feature, you do not have to do anything.
For maintainers of Ubuntu packages in Launchpad, we have left this option enabled. Getting this feature re-enabled was driven largely by requests from Ubuntu developers, so we have not changed the config options for Ubuntu packages in Launchpad.
If you have any other questions about this, feel free to leave a comment here or contact me on Launchpad.
October 6th, 2010 at 7:42 pm
Do you plan to aggregate the emails by recipient address?
As a project owner of 7 launchpad projects I’d rather receive a single email enumerating all of them than the 7 almost-identical emails I actually received.
October 6th, 2010 at 8:20 pm
I think with how fast open source projects are always moving that this is appropriate. If a bug is really that old, chances are it’s already gotten fixed on accident.
October 6th, 2010 at 9:44 pm
@Marius
Too late. I already received 15. :/
October 7th, 2010 at 2:24 am
@marius, what we should have done (and intended to do) is make a list of all of the people who are product owners and able to control this flag, and then send each of them one message. Next time.
I’m just glad expiry’s available again.
October 7th, 2010 at 3:31 am
In what forum were the requests by Ubuntu Developers to enable this forum discussed? I don’t recall seeing this come up again, and was part of a significant group of Ubuntu Developers who were glad when this was disabled years ago. I remain convinced that it is not only useless, but actively harmful to the quality of bugs we manage, especially for the vast majority of Ubuntu packages which have no specific maintainer.
Specifically, we rely upon bugs for information about issues with the software being distributed. Bugs are marked incomplete for a variety of reasons, but those that tend to reach expiry do so either because nobody ever looks at it again, because the bug is very poorly described, or because the bug is difficult to reproduce because it depends on complex interactions (presence or absence of specific other software, complex configuration, etc.), or because it is hardware dependent.
Given that current Ubuntu bugsquad procedures recommend setting incomplete whenever a bug is not trivally reproducible, and the vast majority of bugs are never revisited (and are likely to have been triaged by someone unfamiliar with the software in question), it would be unsuprising to simply discard the majority of reports. Doing so splinters discussion, and encourages the filing of duplicate bugs in the hopes of indicating “This is a new issue” although it may have been present for several years.
These issues are componded in the case of package interactions or hardware-dependent bugs, as by expiring the bugs they are unlikely to appear in searches, so each new person selecting specific hardware or attempting to combine specific packages may have no simple means of determining that they may want to select alternate hardware or alternate package combinations.
Were it the case that Ubuntu was able to effectively triage all bugs within a reasonable amount of time (say, 180 days), it may make sense for this to be enabled. In the specific case of a few fast-moving packages with effective triage participation (e.g. kernel, graphics drivers, etc.) it is more rare that these considerations are important, but these represent only a very small subset of packages for which bugs are tracked (even everything on the Ubuntu Desktop CD represents less than 10% of the packages in Ubuntu).
Without long-term delayed tracking of bugs, we are unable to determine if we are fixing bugs, especially for packages that receive little attention, and cannot effectively discuss the quality of the software we produce. Further, users are unable to determine if a given package just hasn’t had much use in a while, or is of great quality without advanced searches (which are not common views for casual bug inspectors).
October 7th, 2010 at 11:03 am
@Marius, as Martin says, we should have done it this way, but we don’t have any intentions to send these mails again. Next time we have the occasion to send a mass mailing like this, we’ll certainly make sure we send project owners one email.
October 7th, 2010 at 11:19 am
@Emmet you have a lot in there, and I don’t know how well I can respond to all of that in a comment. FWIW, this was discussed at UDS-L in a couple different sessions. There was a recurring theme of people using API scripts to expire bugs and some discussion about how we could get this re-enabled for Launchpad to handle. This is why we added the Expired status, to make it clear which bugs have been expired. As for this leading to dupes, the dupe search tool that runs when you file a bug includes closed bugs, so even Expired bugs are listed. Also, all the people subscribed to the bug will get an email saying the bug has been expired. If someone is interested in keeping their bug alive, they only have to toggle the status back to an open status or comment, much the same as people do for answers on Launchpad now.
I know this was mishandled in the past, but we’re going to great lengths to ensure that we only expire bugs matching the criteria listed at the Launchpad help page, that we clearly mark these with a unique status (EXPIRED), and that we communicate well about this being re-enabled and what it means for our users.
October 12th, 2010 at 3:56 am
@Deryk,
I attended a number of UDS-L sessions about this, and it my understanding that the result was to allow it to be enabled for *some* packages (like the X stack, kernel, etc.). I remain strongly opposed to enabling it for all Ubuntu packages, and very much doubt it is possible to not “mishandle” expiry for packages that receive developer attention less than once a year, and may not receive much attention from bugsquad.
As for “if someone is interested in keeping their bug alive, they only have to toggle the status back to an open status…” I had over 200 bugs in that state for the last transition, and have yet to have time to dig into the current status of each of them. I have never experienced the case that a bug I reported has been resolved with the passage of time and nobody paying attention, and have often experienced the case where people set to “Incomplete” because they can’t be bothered to replicate themselves, or set to incomplete from a script.
Further, I very much believe that such a policy decision on the part of Launchpad ends up reflecting poorly on Ubuntu’s reputation. The packages most likely to be affected by blanket enablement of expiration are those also most likely to have already caused users some frustration as a result of developer inattention: I can’t imagine how having to reset bug statuses can help this perception, nor how “expired” vs. “incomplete” can be useful to a developer who finally gets around to looking at a package for whatever reason.
October 12th, 2010 at 12:56 pm
Emmet, I don’t recall anything about making this configurable per package. I’ll check with those in the Ubuntu QA and release teams to see if they believe this to be a requirement as well. We don’t currently have this configurable per package. It’s a single setting for the distro on Launchpad.
Also, I don’t feel that auto expiring bugs will reflect poorly on Ubuntu’s reputation, but I recognize that we don’t agree on this point and do respect your opinion about it.
January 28th, 2011 at 9:11 pm
@Deryck, has the staged rollout completed now? bzr has expiry turned on, and yet bugs don’t seem to be expiring.
January 31st, 2011 at 4:06 pm
It’s been active for Ubuntu, but not for everyone else. I’ve just put in a request to update the cron entry to remove these restrictions.
We were only expiring 200 at a time and only for Ubuntu because of the great number of bugs needing to be expired. This limitation was decided on during QA to re-enable bug expiry to help control the amount of mail and to make it easier to recover if we made some mistake. Things have been running smoothly for Ubuntu since November, so I think it’s safe to do this across all projects now.
January 31st, 2011 at 6:59 pm
Great.
February 9th, 2011 at 4:55 am
[…] As we foreshadowed last October, bug expiry is now active again. […]
February 9th, 2011 at 4:57 am
This seems to now be active for everyone? Yes, it is: http://blog.launchpad.net/?p=1925
February 9th, 2011 at 12:56 pm
Martin, thanks for the blog post announcing this. I’ve updated the various wiki pages to accurately reflect the current state of things, too.