Mon, 09 Aug 2010

On BTS usage

You might remember that I started to work on closing RC bugs for stable. This effort hasn't died off so I joined the RC Bug Squashing Contest that was going on during the Debian conference (which I was unable to attend). The rules did permit it, even though I was aware that it can't (and shouldn't) be compared to the unstable/testing squashers and thus it was split of into its own Special category.

There still seems to be a lot of confusion on how our BTS works, especially with respect to version tracking. I was even accused of falsely claiming bug closing because the bug has been closed by someone else already. This wasn't the case, otherwise the bugs would had been archived a long time ago already^[1]—given that I had expected that person to know how bug archival works and also given the sheer amount of bugs that I simply had closed for stable, I guess it is needed to shine a light upon why some bugs won't get archived as expected.

If you followed my IRC talk on BTS usage last month you might already have an idea of what's going on. There might be several different reasons why bugs aren't marked for archival yet. I'll try to explain them as I understand it (given that I neither have taken a look at the debbugs code nor am involved with its development) through my working on bugs over the last 10 years.

• Usually bugs are marked for archival when they are not affecting testing or unstable. That means, for a bug filed against a version that is only in unstable and closed in unstable, an immediate archival process is started (actually, it's not that immediate: It requires the package to be in sync on all architectures it's available for, too); otherwise the fix has to enter testing before bugs are considered for archival.
• Sometimes the bug is still considered affecting unstable though, even when the fixing package version already moved over to testing. This is the case when the hurd-i386 package is outdated in unstable and can be checked in the unstable overview of the package on packages.debian.org at the end of the page, it will have red entries next to the green ones (you can ignore red entries for debports architectures, though!). You have to file an arch specific removal request for those bugs to get them archived.
• For packages in experimental it's quite the similar situation, because that packages from experimental don't transition anywhere, so those will stay unarchived for the time being if they also affect unstable.
• So what can be the reason when the fix is already available in testing and unstable but the bug still doesn't get archived? Those cases mean that the bug is considered as affecting stable and has to get addressed there, too. Bugs that are considered for that are of a release-critical severity, bugs with lower severity aren't considered for stable because they are unlikely to get fixed in stable and thus get archived. So what can we do about them?
  • Do they actually really affect stable? Working on those is what I did over the last months. There are often enough bugs filed for library transition issues, FTBFS for toolchain changes, or other things that aren't applicable for stable. Those are easy to close in stable:
    • If the version information got lost (through reassigning or similar), the only thing needed is to re-add the found versions, given that it is a higher one than the one in stable.
    • If the version information is proper (because it had still the same version in unstable at the time of the reporting) tagging them with + squeeze sid will tell the BTS to consider them only for those releases, so not thinking it affects lenny, too.
  • Some do affect stable but still aren't severe enough to warrant an update in stable (like for documentation corrections in debian/copyright or similar). If you found one of those please talk to the release-team about getting them tagged lenny-ignore, don't do that yourself because that tag is meant to be set by the release-team themself only!
  • If they actually affect stable (like security issues that though are considered to be too minor by the security team to warrant a DSA, or other severe usability issues), please try to backport the relevant fix, propose a diff to the release-team on their mailinglist and have it uploaded to lenny-proposed-updates to be fixed in the next point release.

I hope this will get others also interested to fix stuff for stable. Actually when I see something that potential falls into the last group I ping the maintainers of those packages to let them know about having them fixed. Some of you might already have received such a ping and I am thankful for those that received them well and actually already fixed some of those, too. Thanks for making stable a better place!

Coming back to the RCBC, it was an interesting small competition (if only in my brain) between myself and the testing/unstable RC squashers going on. It would had been nice to get at least as many bugs in stable addressed as in testing/unstable because the amount is still a lot higher, but I can still be happy about the things done. And it is good to know that not everything seems to think that it's wasted effort to work on getting the RC count lower for stable, too (like I also was told about my effort). So thanks from that point of view!

^[1] There are currently 2688 bugs still unarchived that were closed last year already! This UDD query helps you:
select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';

/debian | permanent link | Comments: 0

Trackbacks are closed for this story.

• operation::mindcrime (feed)
• Planet Debian (feed)
• Debian-Sicherheitsgutachten (feed)
• planet.gnome-de.org (feed)
• Advogato (feed)