RFC: The BTS, "Severity: Fixed", etc. (Was: An idea for the BTS)
Yann Dirson writes:
> Sure, but it would be nice to have some sort of a mechanism to help us
> to deal with bugs and dists.
>
> I think that we should keep the state of each bug-report regarding
> each dist (stable/frozen/unstable/experimental).
Thinking backward, I don't like my last proposal so much. Here is a
new one:
The main issue is still about how to handle the status of bug reports
wrt each distribution.
As I see it, the `Status' of a bug-report (I suggest at least: clear,
reported, identified, known-workaround, known-fix, fixed) is an issue
that is othogonal to the `Severity' (as used for now: wishlist,
normal, important, grave, critical) - eg. the fact that a bug was
fixed (eg. by a NMR) does not mean it is not important any more.
This means I don't think the "Fixed severity" as suggested some
monthes ago would be a good thing. Rather, I'd like to see
implemented some `Status' fields (or whatever they could be called
better), one for each being-worked-on dist (stable, frozen, unstable).
Proposals:
[Note: I don't know much about the internals of the BTS; I hope this
will be accurate enough, though]
* These fields would be named by the codename of the dist
(eg. `hamm_status') - can this be achieved easily ?
* Their possible values and meanings of these would be:
Clear: the bug never shown up in this dist (case where the bug appears
in a new upstream release)
Reported: default state - nobody know yet what is the cause of the
problem
Identified: the bug logs describe the problem. This status is aimed
at those bugs which are hard to fix, and such situations. Ususally a
status will directly go from `reported' to `known-workaround',
`known-fix' or even `fixed'.
Known-workaround: there is no know fix yet, but the bug logs describe
a way or working around this bug.
Known-fix: a fix is known, maybe described in the bug logs. Usually
a new upload will follow shortly, turning this status into `Fixed'.
Fixed: the last release in this dist fixes the bug.
* A new field in each record of the bug DB would be created when a new
unstable dist is created, inheriting its value from the last one
(eg. slink_status would have inherited from hamm_status).
* When a new bug is reported, the status for each being-worked-on dist
defaults to `reported', unless specified in the pseudo-header (valid
values here: all but `Fixed')
* When a package is installed fixing a bug, the status for the
relevant dist should be set to `Fixed' by `dinstall' (instead of
setting `severity' to `Fixed' as was formerly suggested).
* The status can be modified using `control@bugs' using lines with a
syntax like:
status <bug-number> <dist-name> <new-status>
This is just a first draft, and may be lacking some important issues.
As usual, comments are more than welcome ;)
--
Yann Dirson <ydirson@mygale.org> | Stop making M$-Bill richer & richer,
isp-email: <ydirson@a2points.com> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: