[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?


Reply to: