Re: 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)])
On Mon, 7 Apr 2003, Colin Watson wrote:
> On Mon, Apr 07, 2003 at 03:13:01PM -0500, Drew Scott Daniels wrote:
> > 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
>
> <ahem> Or whoever gets around to doing it first ...
>
I'm still unclear as to what you want to do. As I said before I'm
interested in helping. I guess we can discuss this on the debian-debbugs
list.
I noticed that pending and fixed tags need to be distribution specific as
well as the status.
In http://bugs.debian.org/~cjwatson/version-tracking.html you say assuming
distributions are always a branch is not reliable as the distribution may
have it's "branch" included right into the next distribution? I see that
this is a problem if there is only one place to upload a package, but I
don't think it would be too unreasonable to ask the maintainer to close a
bug in a later distribution or reupload the same package for different
distributions (which they should be unless they don't depend on anything
distribution specific).
How is it decided that a bug is the result of something new that's only in
later distribution(s)? Right now (not including tags) it's assumed that
bugs affect only unstable.
Here's an ascii drawing of the way releases normally branch (semantic
drawing error with testing getting unstable packages for a while).
unstable(new pkg)---> testing1---> stable1 ---> revisions1 (r1...)
|
|-> unstable ---> testing2 ---> stable2 ---> revisions2
|
|-> unstable ---> testing3
|
|-> unstable
Currently revisions1=Potato r7 (2.2r7), revisions2=woody r1 (3.0r1),
testing3=sarge... branch1=potato, branch2=woody, branch3=sarge
A bug could have
- existed starting with the new package
- and was not fixed and all branches are affected
- but was fixed before the first branch (no bug left?)
- but was fixed in the second branch and the bug is left in the first branch
- but was fixed in the third branch and the bug is left in branch 1&2
- been introduced in the second branch
- and was not fixed and the last two branches are affected
- but was fixed in the second branch (no bug left?)
- but was fixed in the third branch, the bug's left in the second branch
- been introduced in the third branch
- and was not fixed, the first two branches are fine, but not 3.
- and was fixed (no bug)
Bugs could also get reintroduced in different branches.
Note: I question whether no bugs are left when stable is fixed as unstable
and testing may not get a fix right away, particularly testing doesn't seem
to get RC bug fixes right away due to the way people expect packages to
propagate from unstable to testing (and sometimes don't ask the RM to
force an update).
Because of this whole mess of problems, I suggest starting with only
scanning the latest entry in the changelog(s) of uploaded packages and
using whatever distribution/version tracking that seems appropriate. I
guess only checking the last changelog is not as thorough and may not
produce desirable results as often and perhaps should only be looked to if
there's problems parsing changelog files.
The big question I have is how are the versions or branches going to be
tracked? A new field or fields? Some method of extending the use of tags?
I'm guessing that it'll be new fields, but what will they be used for and
called?
> (God, I can't decide whether all these threads make me want to give up
> in despair or implement something broken now just so they stop. :P I
> have three weeks of holiday coming up ...)
>
This problem has been around ever since (slink?) stable has had upgrades
(or even longer). I don't want this rushed, or dropped. I'd like people to
know about the problems with the BTS, how they could work around the
problems, and what may come in the future.
Drew Daniels
Reply to: