Re: version tracking plans?
On Fri, Aug 15, 2003 at 09:58:58PM +1000, Anthony Towns wrote:
> reopen should be done away with entirely. submitter replaces one aspect of
> it's functionality but better (dealing with merged bugs).
Notifying the original submitter, too.
> 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.
I think versionless opens and closes should keep on being possible even
for non-pseudopackages so that not-a-bug / yes-it-is-so-a-bug exchanges
are possible. Receiving a versionless open after a versioned close is a
tricky case, but for now I think treating that as meaning "wasn't fixed
anywhere, but not reporting an additional found-in version" would be OK.
I'd like to leave a limited form of reopen around (versionless, doesn't
let you change submitter) for a while at least because I'm a wimp. :-)
> This command definitely doesn't let you change the submitter. (Maybe
> when/if the .status format ever changes this could happen)
The syntax would be a headache ('open <bug#> [<submitter>] [<version>]',
so how would you tell the optional bits apart?), so I think it's better
to leave that out.
I've more or less implemented new open now, I think.
> 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.
How about a command to remove from the list of found versions, as in
"whoops, I made a mistake, I was actually running <foo>"? close isn't
right because you don't necessarily want to claim it's fixed, but just
to retract an earlier confirmation. Maybe "not-open" or "not-found".
"not-fixed" is appealing on grounds of orthogonality but I can't think
of a real use case. Saying that a bug isn't fixed should always be just
like saying you've found that bug.
> The done line in the .status file is used for pseudopackages, which
> don't have any version information stored.
There're also versionless closes (not-a-bug, etc.), which use the done
field.
> 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.
For the common case, versions in .status should be exactly what's
reported in incoming mails. The mail processing scripts don't have any
better idea of what they might mean than anything else does, and if we
delay interpreting them to the time when they need to be interpreted
(i.e. displaying bugs and working out when to expire bugs) then we don't
have to rewrite the database if we change our minds about
interpretation.
We do need to decide what goes in the .status files from katie's
automatic close messages, though. I'd like to decree that we store the
source version in that case: it saves having to deal with version
mappings in process, it saves having to even know about the version
mappings at all until it comes time to interpret the versions, and if
anyone tries to upload foo.deb 1.1 -> foo.dsc 1.0 followed by foo.deb
1.2 -> foo.dsc 1.1 then we visit them with a baseball bat for being
awkward well beyond the call of duty. TBH, I don't think that case is
likely.
If you're looking at a binary package in the web interface and it spots
something that isn't a recorded binary version, it can always convert it
to a binary version for display purposes. This is strictly a display
matter so we don't need to decide straight away.
> 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?
Probably simplest to let this be handled in the same way as renaming of
packages is currently handled, namely that you have to sort out any
stray bugs yourself. Otherwise katie'd have to send debbugs some kind of
wonky message when it spots a package being renamed, and there'd be a
lot of stateful complexity.
Reassigning clears both found and fixed version lists, possibly unless
the source and target are from the same source package. If the latter,
this would be the one part of mail processing that knows about binary
<-> source mappings, but that should be OK here.
> 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?
Yeah. We only need to keep deb/dsc mappings that aren't the simple case
of source version == binary version and one binary package per source
package, which should save some space and time reading the mappings. The
need to remember about old binary package arrangements means that we
can't just use the Packages file to map binary package names to source
package names, so we do have to keep a little information about every
multi-binary package, which is a bit of a pain, but hey. Not sure how
best to store all of this yet.
> 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.
(This is so that neither katie has to depend on a working network
connection to debbugs or vice versa at any time, BTW. Mail would in
theory be OK but authentication would be nice, so something over ssh is
easier.)
> 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?
debbugs needs to get the binary package names as well in katie's -done
messages so that it can do the suggested new thing of protecting -done
against spurious closing messages for the wrong packages (it might not
have the latest triggered stuff at that point). So:
Source-Package: foo
Source-Version: 1.0
Packages: foo, bar
This is simpler than the previously hypothesized Packages: header
because you can get away without binary versions. If Packages: ==
Source-Package:, just omit it.
> 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.
Yup, although I'd really like cvs.debian.org to be back first so that I
can see what I'm doing. If I get it right the output will be identical
for now unless you do &versiontest=yes.
.status files: unless doogie does the new format RSN I'm just going to
have to append two lines to the current format. Sorry.
The main remaining headache I have is how to do new expire: we suddenly
need to keep state because you can't infer when a particular version
e.g. reached testing just from the .log's mtime. Should be a Simple
Matter Of Programming but I thought I'd mention it.
A final suggestion: looking at old versions in the web interface should
look through archived bugs as well and find any that were open against
those versions. Otherwise seeing what bugs were open in stable is going
to be very non-intuitive. This will obviously be slower, but it's a
complex non-default query so I think people will put up with that.
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: