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 > ------------------- Yay! > [...] > 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: 1.4.1.6 > slink: 1.4.0.35 > 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 straightforward. 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 1.4.1.5, then it's fixed in potato, but not > slink or experimental (since experimental is a fork from 1.4.0). [...] (where dpkg 1.4.0.35 is in slink, 1.5.4 is in experimental, and 1.4.1.6 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.6 1.4.1.5 1.4.1.4 1.4.1.3 1.4.1.2 1.4.1.1 1.4.1 1.4.0.31 1.4.0.30 > 1.4.0.29 1.4.0.28 1.4.0.27 1.4.0.26.0.1 1.4.0.26 1.4.0.25 1.4.0.24 > 1.4.0.23.2 1.4.0.23.1 1.4.0.23 1.4.0.22 1.4.0.21 1.4.0.20 1.4.0.19 > 1.4.0.18 1.4.0.17 1.4.0.16 1.4.0.15 1.4.0.14 1.4.0.13 1.4.0.12 > 1.4.0.11 1.4.0.10 1.4.0.9 1.4.0.8 1.4.0.7 1.4.0.6 1.4.0.5 1.4.0.4 > 1.4.0.3 1.4.0.2 1.4.0.1 1.4.0 > 1.4.0.35 1.4.0.34 1.4.0.33 1.4.0.32 > > That is, a list generated straight from the packages' changelogs (1.4.0.35 > was based on 1.4.0.34, which wsa based on 1.4.0.33...), 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 1.4.0.32 was based on 1.4.0.31. > Get the bugs archived > --------------------- Yay! > Change the database format > -------------------------- Awww. 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:
pgpiRibGV13Uq.pgp
Description: PGP signature