BTS imporovements? (was Re: [PROPOSAL] Debian Release Plan)
>> For that matter, I can't seriously believe that new XFree86 should >not
>> be released because of bugs which are pre-existing in old XFree86
>> (#143825, #185936, #190323). This is actually a *very* common
>problem;
>> a lot of RC bugs existed in older (released) versions, and so
>shouldn't
>> be considered blocking if they happen to still be present in newer
>> versions, but the 'testing' scripts don't realize this because the
>>bugs
>> weren't *reported* earlier. (Actually, rumor has it that there's a
>> 'sarge-ignore' tag available now, which may do the right thing for
>> supposedly RC bugs which shouldn't really block release; I don't know
>> much about it though.)
>
>Just to fend this off now, you should absolutely not use the
>sarge-ignore tag without explicit authorization from the RM. I believe
>that aj's going to be making some kind of announcement about this in
>the near future anyway, though.
So it's solely for the RM's direct use. OK. Then another solution is
needed.
The testing scripts could recognize that 'sarge,sid' bugs do *not*
represent an increase in the number of RC bugs (and, for that matter,
that 'sarge' bugs represent a *decrease* in the number of RC bugs).
This seems straightforward enough, although it requires a rewrite of
the bug count mechanics in the 'testing' scripts, including a new (but
backward-compatible) method of storing 'bugs in testing'. Maybe I
submit a patch to make the testing scripts do that?... but it'll still
be approximate.
So perhaps I should hit the problem at its source first by allowing the
BTS to recognize bug reports as being present/absent in specific package
version?
--
I believe what is needed minimally is the following:
First-Version-Buggy field, containing the first version the bug is known
to be present in. Initialized to the version specified by the
submitter, but changeable. (Empty should probably mean 'may not really
exist', which would be set for unreproducible bugs.)
First-Version-Fixed field, containing the first version in which the bug
is fixed. Empty means 'not fixed yet', which is the initial value; also
freely changeable.
The assumption can then be made that the bug exists precisely in those
versions with First-Version-Buggy <= version < First-Version-Fixed.
(It's a rare bug which doesn't behave this way, and given that, opening
a separate bug for the 'revival' of a previously fixed bug is
reasonable. There is a separate issue with backported fixes to 'stable'
generating such patterns quite often. But perhaps that could be dealt
with in an ad-hoc manner given the limited number of such backports. If
not, there is a slightly more complicated scheme wherein
Version-Introducing-Bug is a list and so is Version-Fixing-Bug, which
solves this entirely.)
Uploads using "Closes: Bug #xxx" can then set the First-Version-Fixed
field automatically. (It might be reasonable to make it not actually
close the bug, and have the bug closed only when a fixed version is in
'stable'. But that would call for some additional enhancements to the
BTS interface to make it easy to grab only the bugs in unstable.)
The 'testing' scripts, rather than keeping a guesstimate of the number
of RC bugs in 'testing', check the version number in 'testing', and for
the bugs against the package, check which ones are present in 'testing'
by version number comparison. Similarly to get a count of the RC bugs
in 'unstable'.
For transition purposes, the 'woody', 'sarge', and 'sid' tags (and most
combinations of them) can be translated directly to First-Version-Buggy
and First-Version-Fixed fields. ('woody' by itself, for instance,
translates to First-Version-Buggy: <woody version>, First-Version-Fixed:
<sarge version>.) Untagged bugs get marked with First-Version-Buggy:
<woody version> and First-Version-Fixed: <not fixed yet>.
This would cause a fairly large amount of interaction between the
testing scripts and the BTS; if this turns into a problem, there might
be some way to streamline the communication.
Reassignment to a different package should reset the First-Version-Buggy
and First-Version-Fixed fields to appropriate generic choices for the
new package.
The fields would be ignored and meaningless for pseudo-packages.
This would *not* work well, at least directly, for bugs assigned to
multiple packages. Perhaps this could be dealt with in a simplistic way
by using Version-Introducing-Bug and Version-Fixing-Bug, and making them
lists of package-version pairs. Sanity checking that the packages
corresponded to packages which the bug was assigned to would be
necessary. :-/
I'm not too fond of multiple-package bugs, anyway, as they usually
indicate either:
* a bug where it hasn't been determined which package is responsible
(unavoidable sometimes, but should eventually be assigned to one)
* multiple similar bugs in one (a bad idea)
So perhaps it would be OK to simply ignore all but the first package
assigned to, at least as a first attempt.
Shall I work up some patches to the BTS (this can be done
incrementally), or is this scheme not desired?
--Nathanael
Reply to: