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 [EMAIL PROTECTED]' 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 <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
