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