Hi folks, after reading a recent reply from Manoj to Ian about whom is the intended audience of bug reports, I arrived at a different perspective than I previously had and with it came a new approach to address the situation of bug severity and rc status. Below is the relevant snippet: ---------------------------------------------------------------------------- Message-id: <[🔎] 87iri72o5m.fsf@glaurung.internal.golden-gryphon.com> On Thu, 26 Oct 2006 12:02:31 +0100, Ian Jackson <ian@davenant.greenend.org.uk> said: > Manoj Srivastava writes ("Re: Bug mass filling"): >> On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <major snip> <snip about severity and rc-ness> A very developer centeric view. But there are other people in the community; and as a general statement this falls far short of the mark for which bug severities are actually useful for. Bug severities have one other purpose, and perhaps the most important of all: It lets people know whether or not it is OK to upgrade or install a package, and but severities are one way of gauging a release' quality. While only partially relevant to this case, you are making what seems like a general statement, and missing important bits. <major snip> So, policy guidelines as to bug severities are a cheap way to arrive at a consistent default for bug severities, and there is no reason not to add such guidance, as long as the guidelines are flexible, and, more importantly, correct. ---------------------------------------------------------------------------- I propose that there are 3 parties involved in each bug report: user, maintainer, and release manager. The bug report is generated by a user to communicate to the maintainer information that can alert the maintainer about a problem with the package. After reading the bug report, the maintainer determines what severity to assign to a bug report. This conveys the seriousness in which the bug affects the user. And as Manoj points out, is used as a gauge for package upgrade decisions. I use apt-listbugs which greatly aides this decision. Now, the rc nature of a bug can not mechanically be determines as has been pointed out. This would seems to eliminate the link between rc status and bug severity. Instead, I propose a usertag 'rc-$stable' (e.g rc-woody for rc bugs that affect woody). Rc bugs, by definition, affect a release and a release is not an unlimited length of time. And secondly, I propose the continued use of '$stable-ignore' for rc bugs that should be ignore for a release. This is where this leads: IF RC-$stable usertag THEN IF $stable-ignore THEN echo 'this rc bug for $stable is to be ignored' ELSE echo 'this is an rc bug for $stable' FI ELSE echo 'this is not an rc bug' FI This clarifies how to determine what is rc and what is not. I would propose that as a bug severity is a communication between user and maintainer, the 2 usertags of $stable-ignore and rc-$stable are a communication between release manager and maintainer, and thus are not for the user. So: user<------->maintainer<-------->release manager bug severity $stable-ignore rc-$stable each have distinct purposes, audiences and usefulness. Also, in regards to possible implemation suggests, I have a few: 1) have the bts automatically add a usertag of rc-$stable if the bug severity is high enough. And the release manager can add $stable-ignore to counteract that. 2)at the end of a release, there could be an programmatic adding of unresolved rc bugs to the next release. (e.g. ------------------------------------------------------------------ time=end of release of woody for all bugs that have rc-woody usertags that are open bugs, add the usertag rc-sarge ------------------------------------------------------------------ this would allow for an easy way to alert the next release manager and maintainer as to the work for the next release. happy hacking, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System | go to counter.li.org and | | `- http://www.debian.org/ | be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org |
Attachment:
signature.asc
Description: Digital signature