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

bts solution to rc status via metatags

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 
 IF $stable-ignore 
   echo 'this rc bug for $stable is to be ignored'
  echo 'this is an rc bug for $stable'
 echo 'this is not an rc bug'

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
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,
|  .''`.  == 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

Reply to: