On Fri, Aug 15, 2003 at 07:57:52PM -0500, Colin Watson wrote:
> > 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".
I'm inclined towards:
] open 123456 1.0-1
] close 123456 1.0-1
being the way to do it. The only case for which that doesn't work is if you
want:
] open 123456 1.0-1
] open 123456 1.0-2
] unopen 123456 1.0-2
to leave the bug as "open" in 1.0-2 (because -2 was based on -1 and the
only information left is that it was open in -1). I think that's less
useful than encouraging people to actually check whether the bug exists
in 1.0-2 and decisively say "yes, it is in 1.0-2" or "no, it isn't".
At the very least, open and close are good enough, and we can add an extra
"unopen"/"unclose" command later if it turns out to be needed.
> > 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.
I'd much rather have "not-a-bug" closes just say:
] Package: foo
] Version: 1.0-1
] close 123456 1.0-1
] thanks
] That's not a bug, even in version 1.0-1, ya dork.
I'd be half inclined towards having:
] close 123456
be treated as
] close 123456 <version-currently-in-unstable>
by the BTS for packages with version trees. (With fallbacks to
experimental, testing-proposed-updates, testing, proposed-updates,
stable, old-proposed-updates, oldstable, in that order say)
> For the common case, versions in .status should be exactly what's
> reported in incoming mails.
For compatability with reportbug etc, what's in incoming mails (Package:
/ Version:) will be the binary version (except for packages that only have
a .dsc by that name, no .deb). So that's what we're storing.
> 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.
That's not possible. Changing the "interpretation" means having the
interpretation be wrong for >50% of the bugs either before or after the
change, which is unacceptable.
> We do need to decide what goes in the .status files from katie's
> automatic close messages, though.
By the above, what goes in the .status file are binary version numbers.
The only question left is how we _get_ those binary version numbers.
> I'd like to decree that we store the
> source version in that case:
Not possible. Well, strictly it is. What you could do is store:
bin-versions: [binary -> source]
foo 1.0a-1 foo 1.0-1
foo 1.0a-1.0.1 foo 1.0-1
bar 1.0a-1 foo 1.0-1
foo 1.0b-2 foo 1.0-2
package: foo
found-in: 1.0a-1
fixed-in: s_1.0-2
And treat any version with a leading "s_" as a source version, and map
it to all the corresponding binary versions. So "s_1.0-1" for foo, is the
same as "10a-1 1.0a-1.0.1" and "s_1.0-2" is the same as "1.0b-2". I'm not
sure how you then work out that any bug found in 1.0a-1.0.1 is going to
also appear in 1.0a-1.0.2 or 1.0a-2. You might have to map the other way,
although I'm not remotely sure how you'd deal with:
] open 123456 1.0-1
] # miscompiled on alpha
] close 123456 1.0-1.0.1
] # binnmu on alpha, no source changes
] open 123457 1.0-1.0.1
] # binnmu broken!
] close 123457 1.0-1.0.2
] # binnmu fixed!
I'm not sure how you'd _want_ to deal with this case though.
You syntax would then be something like:
Package: bar
Version: 1.0a-1
Source-Package: foo
Source-Version: 1.0-1
with users normally using the former, and katie normally using the latter.
> 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.
I think this has all the benefits you're looking for here, without making
the .status file a matter of interpretation, so wins on all counts. It also
lets us separate bugs against foo.deb and foo.dsc reasonable sensibly, rather
than having to drop support for one or the other.
> > 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.
I'm not convinced that optimisation is correct: I suspect we need to
know when foo.deb 1.0-1 *doesn't* actually match foo.dsc 1.0-1 as well.
Not sure it's worth worrying about space for a little while anyway.
> 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.
It has to be in a single file, so that you don't have to know about foo.dsc
in advance to work out where to look for info about bar.deb. Probably. How
we handle package splits might affect this.
> 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.
We can if we send a mail to someone to say that "a version fixing this
bug has propogated to testing" as part of getting a new packages file
for testing. Then the logic is:
(a) get a new packages file for sarge call it sarge-NEW
(b) for every bug tagged sarge, that's not fixed in sarge,
but is fixed in sarge-NEW, send an email saying it's now
fixed in sarge (useful! hacky!)
(c) for every bug tagged sarge, that's fixed in sarge, but
reopened in sarge-NEW, send an email saying it's broke again?
(optional, doesn't affect any other functionality)
(d) replace sarge with sarge-NEW
(1) check through every bug that hasn't been touched for 30 days
(2) if it's open in unstable or experimental, ignore it
(3) if it's tagged {potato, woody, sarge}, and is open in the
respective suite, ignore it
(4) otherwise, archive the bug
Fairly straightforward, correct, and the hacky bits are actually useful
features, I think.
> 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.
It'd be nice, but we'll have to muss with indexing to do it. I vote leave it
for later.
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:
pgpgyQmz3aw5S.pgp
Description: PGP signature