[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: My Wishlist



On Mon, Oct 28, 2002 at 12:30:11AM +1000, Anthony Towns wrote:
> So, a blast from the past:

I'm taking silence as assent, but some more info in the meantime.

> > Per-Release Reports
> > -------------------
> > I also think it'd be nice to be able to say "these bugs are relevant to
> > slink, these to potato, and these to experimental". [...]
> The other part we need to do is have some way for control@b.d.o to handle
> which versions of a package are affected. [...]
> [...]
> 
> So, that's the first step: add two new lines to .status to store
> the two lists of versions the bug applies to, and add some commands
> to control@b.d.o, and make use the Version: pseudo-header. This will
> probably completely break "debbugs.trace", of course.
>
> The second step is probably to add this to the CGIs, which should be
> straightforward.

There are a couple of subtleties. My current plan is to make

	http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=foo

show active (ie, unarchived) bugs for the version in unstable. This means
if a bug against foo has been found in versions X and Z, and fixed in
versions Y and W, with X < Y < Z < W, then it'll be shown if the version
is X <= ver < Y or Z <= ver < W. That is, the bug's been found in this
version or a previous version, but hasn't been fixed yet.

This means if X 4.2 is in the archive, and you file a bug against one
of the packages from X 4.3, then your bug *won't be displayed*. The
best way of handling this seems to be bouncing the report back to the
submitter: if it's from a third party it should definitely be going to
their BTS anyway, and most maintainers actively discourage filing bug
reports about experimental packages. For the rest, the packages should
probably just be being uploaded to experimental anyway.

Finally, this makes it difficult to work out when to archive a bug. Should
it be done when the bug is fixed in unstable or stable? The right
answer seems to depend on the particular bug -- security problems are
best archived only when they're fixed everywhere, typos aren't going to
make a point-revision or hurt anyone anyway so there's no point worrying
about them. I'm planning on (ab)using the potato/woody/etc tags for this,
so that bugs will be archived by default when they're fixed in unstable,
but if they've been tagged "potato woody" they'll be archived as soon as
they're fixed in unstable, potato and woody. Experimental should probably
just be treated the same way as unstable. The "thirty days delay just in
case" should be taken as implied. I think archiving's necessary to avoid
old bugs getting filled up with spam. An "unarchive" command for control@
could still be worthwhile, of course.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Attachment: pgp0R4sARIwgO.pgp
Description: PGP signature


Reply to: