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

Re: My Wishlist

So, a blast from the past:

On Mon, Sep 13, 1999 at 11:03:41PM +1000, Anthony Towns wrote:
> I'd like to see some or all of the following added to debbugs:
> CGI-based web pages
> -------------------


> [...]

> Integrated Reports
> ------------------
> We've got a few cutesy bug summary things about, including -bug-reports,
> the RC bugs list, the old bugs list and the non-wishlist graph. I'd like
> to see all these generated by the BTS itself, and made available on the
> website. With graphs and all.

Awww. :(

> Per-Release Reports
> -------------------

(The point of this message)

> 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". A nice (and I suspect
> easy) extension would be to add "...and these in the perl staging area,
> these in the gnome staging are, and these in the kde staging area".
> But focussing on just stable, unstable and experimental.
> I think we need to teach the BTS three things. 
> First, we need to tell it which version of which package is in which
> distribution. Taking dpkg as an example:
> 	potato:                                               
> 	slink:                                               
> 	experimental: 1.5.4
> Next, we need to tell it which version(s) of a package closes a particular
> bug. dinstall can deal with this quite easily, and it's not too tricky
> an addition to the control@b.d.o syntax, although figuring out what to
> do with a foo-done@b.d.o, might require some thought.

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. Probably the best way to go about
it is to note which versions of a package fix the bug, which versions the
bugs been reported in, and interpolate. So:

	found-in: 1.0-3, 1.3-4, 1.3-5
	fixed-in: 1.3-2, 1.3-4.1

might be plausible, and would imply the bug's present in version 1.3-3, eg.

A message to control@b.d.o saying:

	fixed 123456 in 1.3-6

(or similar) would let you add "1.3-6" to the fixed-in list. A message to
control@b.d.o saying:

	fixed 123456 in 1.3-5

would remove 1.3-5 from the found-in list as well.

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

I've skipped over one thing:

> Then, we need to teach the BTS how to handle intermediate revisions. So
> if a bug is fixed in dpkg, then it's fixed in potato, but not
> slink or experimental (since experimental is a fork from 1.4.0). [...]

(where dpkg is in slink, 1.5.4 is in experimental, and
is in potato)

The easiest way to handle this is just to use dpkg --compare-versions for
all the comparisons. It should be possible to use the information from
the package changelog to work out if any version numbers were skipped,
but getting this info to the BTS isn't trivial. If done, this would let
us handle "fixed-in-NMU" bugs much more nicely: as soon as a version
not based on the NMU series is uploaded, all the bugs that were closed
in the NMUs are automagically noted as no-longer fixed. Which would be
nice, but doesn't make the doing any easier.

This would be the "third step". :-/

The data you need is something like:

> 1.5.4 1.5.0 1.5-iwj.0.4 1.5-iwj.0.3 1.5-iwj.0.2 1.5-iwj.0.1 1.4.0 1.3.14
> 	1.3.13 1.3.12 1.3.11 1.3.10 ...
> 1.4.1
> 1.4.0
> That is, a list generated straight from the packages' changelogs (
> was based on, which wsa based on, but truncated so
> that if we already knew 1.4.0 was based on 1.3.14 and so on, we don't have
> to repeat that later. Ditto that was based on

> Get the bugs archived
> ---------------------


> Change the database format
> --------------------------



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: pgpiRibGV13Uq.pgp
Description: PGP signature

Reply to: