On Fri, Aug 01, 2003 at 11:40:34AM +1000, Anthony Towns wrote:
> ] package foo
> ] reopen 123456 1.2.3-1
> ] Source: foo
> ] Version: 1
> ] Packages:
> ] foo (1x)
> ] bar (3.14x)
Soo. Some discussion on IRC with Colin resulted in the following.
reopen should be done away with entirely. submitter replaces one aspect of
it's functionality but better (dealing with merged bugs). A new command,
open, should replace the other half, functioning like:
open <bug#> [<version>]
Possibly multiple versions could be accepted. Possibly <version> could be
optional precisely when the bug is filed against a pseudo package.
This command definitely doesn't let you change the submitter. (Maybe
when/if the .status format ever changes this could happen)
Version: processing needs to be added to -done processing. Eventually a
pseudo-header should be required for emails to -done to avoid bugs being
closed by spam, or accident.
Add two lines to .status, containing space separated versions. One line
has fixed versions. The other line found versions. "open" adds to one
line. "close" adds to the other. Likewise submit@ and -done. The done line
in the .status file is used for pseudopackages, which don't have any version
information stored. Otherwise it's either empty, or it matches the email
of the person who made the most recent close. The sequence:
close 123 1.0 by ajt@debian.org
close 123 1.1 by cjwatson@debian.org
open 123 1.0
leaves the bug closed by cjwatson. The sequence:
close 123 1.0 by ajt@debian.org
close 123 1.1 by cjwatson@debian.org
open 123 1.0
leaves the done field empty. The done field is cleared precisely when
an open command is received for the rightmost version in the fixed-in line.
It's changed everytime a close or -done mail is received.
Pseudopackages are precisely those packages that don't have a version tree.
To sets of version info need to be stored for each package. One is the version
tree, based on the changelog information, for each source package. The other
is the historical binary <-> source version and package name mapping. This
is a many to one relation -- each binary package/version has a single source
package/version; but a single source may have many packages/versions. So:
foo.deb 1.0 -> bar.dsc 1a
foo.deb 1.1 -> bar.dsc 1a (on a different architecture)
bar.deb 1.1 -> bar.dsc 1a
foo.deb 1.2 -> foo.dsc 1.2 (split out)
foo.deb 1.2 X> bar.dsc 1a (not allowed, even across arches)
Not sure it's clear how to cope with all these possibilities. Does
this mean versions in the .status file should always be source
versions? Probably not. What happens when a package splits? Do the
bugs belong to the old source? The new source? How's the connection
made? Automatically? Manually by maintaining good changelogs? Manually
by telling the BTS which bugs to carry forward, and letting the others
automagically disappear?
We don't have all the historical information for deb/dsc mappings, but
that shouldn't matter too much. We might be able to get much of it from
snapshot.debian.org though?
katie/dak/dinstall/ftp.debian.org needs to send debbugs the changelog
on every source upload; and the binary mappings (from the .katie files)
on every binary upload. "send" means dump in a directory somewhere and
either run a script to trigger debbugs, or just let debbugs rsync it.
katie also needs to include version information in her -done messages. What
version information exactly? Is:
Source-Package: foo
Source-Version: 1.0
enough? Can debbugs use the triggered stuff above to work out the
rest? Should it? (That'd be slightly easier to implement in katie than
the Packages: header hypothesised above)
Colin'll probably roll out the CGI's this weekend -- that'll be a
non-event hopefully, since the .status files haven't changed, but will
get us moving.
BTW, there's a fixed-in-experimental tag now, which is set by katie for
uploads to experimental. Hopefully it'll be obsoleted RSN.
Think that's it.
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.
``Is this some kind of psych test?
Am I getting paid for this?''
Attachment:
pgp28kM7zcRxG.pgp
Description: PGP signature