On Sat, May 04, 2002 at 04:05:39PM +1000, Anthony Towns wrote:
> On Fri, May 03, 2002 at 05:27:30PM +0200, Marcus Brinkmann wrote:
> > On Fri, May 03, 2002 at 08:16:32PM +1000, Anthony Towns wrote:
> > > On Thu, May 02, 2002 at 07:15:09PM -0400, Joey Hess wrote:
> > > > Seems to me that if bug severity is orthagonal to release criticality
> > > People keep saying that, but it's not true [0]. "Release critical bugs"
> > > are those that are serious, grave or critical.
> > Either this is not true, or the BTS documentation is wrong. [[hurd isn't
> > treated the same as i386]]
>
> There are many unwritten rules about how bugs need to be treated,
> and they change depending on what seems the best way to get a working
> release out. In particular, filing hurd bugs at high severities before
> release (especially when people are already uploading relatively untested
> packages with high urgencies) seems likely to lower the quality of woody
> dramatically.
Is important a high severity? According to you, only bugs with severity
serious or higher affect the release. According to Ryan Murray, all
hurd-i386 related bugs are merely wishlist. Someone on IRC (Culus, IIRC)
suggested on IRC (maybe jokingly) that I do not file Hurd bugs in the BTS at
all.
And, why should the severity only be useful for the release manager, and
released architectures? This is a waste of bits, we have the feature right
there but can't use it, instead you suggest to "hax0r" it.
> Adding "arch" tags aren't possible in the short term,
> and it's not particularly clear that they'd be helpful at solving that
> particular problem.
Why are they not possible? Why would they not be helpful, whereas I
described here and in my mail to [EMAIL PROTECTED] (for which I did not
get a reply so far) how they were helpful to me (or anybody in this
situation)?
> You're quite welcome to hax0r the BTS slightly to make
> it easier to track hurd bugs. You can, eg, add your own
> pseudo-header to say "X-This-Is-RC-For-Hurd: yes" and then
> grep through the bug spool later to find them all again and
> upgrade them when you are actually near release. Or have a
> special submitter address ("debian-hurd@lists.debian.org") and use
> http://bugs.debian.org/from:debian-hurd@lists.debian.org to look over
> them.
Why are arch tags not helping with exactly this?
> Helping hurd release sometime in the next few years isn't important
> enough to risk breaking Linux/i386 now.
Why should this be so? I am quite dissatisfied with comments like that,
because noboy ever gave me convincing reasons (or any reasons for that matter),
why a report like:
Package: foo
Version: x.y
Severity: grave
Architecture: hurd-i386
should be even seen by the release manager, break Linux/i386 (sic) or be
detrimential to the quality of a release. The same goes for a Severity of
important without an architecture tag, but with a text that makes it clear
that this is a Hurd bug, and thus not release critical.
You will have to talk me out of this at a finer level of detail. I can
not happily "hax0r" the BTS when I don't understand why a cleaner solution
is not workable, and, so far, I have heard no rationale from anybody why
anything I could possibly do that makes sense breaks "Linux/i386".
I don't want to break anything. I have avoided filing serious or greater
bugs for Hurd issues (except for Hurd-only packages) exactly in mind of the
release process. I file only up to severity important and even get shit for
that. If the severity is only for the use of the release, then give it
another name, because it certainly has not the meaning anymore that is
documented in the BTS file bug-maint-info.txt.
Thanks,
Marcus
"A grave bug is a grave bug."
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
