RC bug tracking (was handling open security problems in woody with the BTS (here: thekernel)[was: Re: Bug#176178 acknowledged by developer (do not reopen)])
The Debian Developer's reference section 5.8.3 [1] section 6 which says
"Once a corrected package is available in the unstable distribution, you
can close the bug." I see no other policy on this, but I have seen
comments about this in the past that suggest waiting until RC bugs are
fixed in all Debian distributions before closing the bug is the most
widely desired/accepted convention[2]. Where else might RC bugs be
tracked[3]?
Tracking RC bugs in stable is difficult for many reasons, not the least of
which is that when people close bugs in their changelogs of their unstable
package it closes the bug for all Debian distributions. RC bugs at least
need to be tracked by the security team (security ones only), the Release
Manager, the "stable release manager" (whatever you call what Joey does at
[9]) and is useful to others others (like me who enjoys tracking security
bugs).
Colin Watson said "if a bug needs to be fixed in more than one
distribution then the maintainer should leave it open (possibly with tags)
until it has been fixed in all those distributions. Otherwise it is left
up to the maintainer's discretion to close it appropriately." [4] I would
tend to agree and point out that many people think that only RC bugs
*need* to be fixed in more than one distribution. If a bug isn't an RC bug
then it should probably be closed once it is fixed in unstable, or perhaps
testing if the maintainer desires. Maintainers are free to keep bugs open
that effect distributions like potato as a reference point for people
although they should probably at least tag them wontfix and note that the
distribution won't be updated to fix their non-RC bug.
Common sense tells me that an RC bug should stay open until it is fixed in
all Debian distributions that it affects, although I notice this is not
always done. Because of bugs like this one and a few others[5] I think it
might be a good idea to have policy updated to address this issue. Perhaps
we should wait for Colin Watson's version tracking features for the BTS
and then add something about it in policy or at least the Developer's
reference.
Aj wished for extra control messages for the Debian BTS and suggested version
tracking[6]. http://bugs.debian.org/~cjwatson/version-tracking.html talks
about what Colin Watson is working on to allow for version tracking of
bugs. Version tracking is what's needed for RC bugs in stable and old
stable like this one[7].
As mentioned in this thread, proposed-updates don't always get accepted.
Take a look at potato's last proposed-updates, although that's another
issue[8]. There's also proposed-updates which are not accepted because
they break things and perhaps other reasons[9]. Uploads to proposed-updates
should be tagged pending, although I think the pending tag should probably
only be set when a package is pending in *all* affected Debian
distributions.
I think the tags potato, woody, sarge and sid should all be extended, but
Colin Watson thinks they should die [10]. It's still unclear to me what
they do, but I know for sure that it's good to set them for bugs that
affect only one Debian distribution. Their usage can easily be interpreted
to mean that a bug affects only one of the distributions tagged or all the
distributions tagged. I believe the tags were created when it was believed
that a bug would effect only one distribution or another and were not meant
to support old RC bugs.
This post isn't as well organized or as readable as I'd like, but it's
taking far to long to write. I think I've demonstrated that there does
exist a need for version tracking (or branch/distribution tracking as I'd
like it to be envisioned), and there is some guidance needed for Debian
BTS users (whether it be policy or just a documented convention somewhere
like the Developer's Reference).
[1] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-housekeeping
[2] Some in the BTS, some in Debian-devel. Maybe try searching for
proposed-updates or "close bug" or "closed bug" in debian-devel.
[3] mdz of the security team tracks security RC bugs and is writing an
interface for his tracking which may or may not be public. This doesn't
include non-security RC bugs though afaik.
[4] http://lists.debian.org/debian-mentors/2003/debian-mentors-200304/msg00047.html
[5] I bring "improperly" closed RC bugs back as I find them, or others
have found and brought them back, but this should not be relied upon.
[6] http://lists.debian.org/debian-debbugs/2002/debian-debbugs-200210/msg00033.html
with more discussion the next month starting with
http://lists.debian.org/debian-debbugs/2002/debian-debbugs-200211/msg00000.html
[7] I didn't check if *this* bug was in old stable.
[8] Potato probably won't (and shouldn't) be updated anymore as it's not
supported by anyone but security or non-Debian. Personally I think it
should be supported one year past the initial release of the next stable
to allow time for regression checking and other things that Debian users
may desire.
[9] http://people.debian.org/~joey/stable.html contains links to details
about why some proposed-updates weren't accepted.
[10] http://lists.debian.org/debian-mentors/2003/debian-mentors-200304/msg00081.html
Drew Daniels
Reply to: