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

Bug#97671: RFD: Essential packages, /, and /usr

On Sat, Jun 22, 2002 at 01:13:47AM +1000, Anthony Towns wrote:
> Then please, pay attention. I've explained this a dozen times on this
> list already, so if you need a different wording surely there's someone
> out there how can provide it.
> Release critical bugs are _very_ rare. They're not for problems that we're
> annoyed or embarrased about having, they're not for policy violations
> in general, they're not for setting goals that need to be done in lots
> of packages.
> They are *purely* for those issues which are so severe that they're worth
> removing packages because of, or saying "I'm sorry, we can't release on the
> day I said, because these issues are unresolved."
> I had hoped that letting policy have some influence on which policy issues
> should be considered release-critical would help ensure consistency
> and a deeper analysis of potential release-critical issues. Instead it
> seems to be an excuse for people to raise every other policy issue to
> release-critical status, and I have to either repeatedly argue against
> it and live with all the mistakes made anyway (like the "must" idiocy
> related to /bin/sh).
> And yes, after eighteen months to two years of having to explain this
> again and again and again and again -- in spite of it being pretty
> clearly written in policy itself -- my patience is pretty short on the
> whole issue.

If Mohammed cannot go to the mountain, perhaps the mountain must come to

We discussed this on IRC a month or so ago.  For the benefit of everyone
else here, I'll re-hash it as I remember it.  Feel free to correct me if
I've misremembered.


* "Release critical bugs are _very_ rare."; and
* Release critical bugs should be the domain of the Release Manager,

Then we really don't need a tight connection between the "serious"
severity and release-criticality at all.  Release-criticality can be a
tag -- whether that is expressed in debbugs along with "security",
"moreinfo", "patch" and so forth or in a webpage like bugscan is

This tag -- no matter how it is expressed -- is the Release Manager's
domain.  People can propose that a bug be treated as release-critical
and, perhaps, if it seems warranted, we can make this a debbugs tag and
possibly automatically set it for all critical, grave, and serious bugs.

The Release Manager can strip the "release-critical" tag off of any bug
he wants.  This is how things have *always* worked in reality.  If a bug
is truly a showstopper for a release, we don't release with it.  We
either wait, fix the bug, or drop the package.

I honestly believe this mechanism would head off most of these catfights
at the pass.  Proper usage of "must" vs. "should" in the Policy manual?
Immaterial.  Mass-filing of serious bugs as public service or
masturbatory frenzy?  Immaterial.  Release-critical?  Release Manager's
call, period (unless someone bothers to appeal to the Technical
Committee -- not a process that is likely to get one a speedy remedy :).

And, while we're at it, this would enable us to re-establish a
maintainer's discretionary power over bug severities, even "serious"
ones.  As Josip Rodin noted in debian-devel, sometimes even a violation
of a "must" directive really isn't a big deal.  Sometimes it just
doesn't make that much difference.  Whether that's due to policy
inflating the importance of compliance with a certain detail, or due to
unusual circumstances doesn't matter.  The Release Manager gets to
attach the "release-critical" tag to any bug he wants, and the package
maintainer is expected to act on that bug if he wants his package to
release with Debian.  If he doesn't, he can alter the severities of his
bugs pretty much at his discretion.

There is a lot more discussion of this issue in the logs of Bug #97671.


N.B.: the above is my recollection of a conversation, and should not be
construed as representing the opinions of anyone else unless they say

G. Branden Robinson                |    I've made up my mind.  Don't try to
Debian GNU/Linux                   |    confuse me with the facts.
branden@debian.org                 |    -- Indiana Senator Earl Landgrebe
http://people.debian.org/~branden/ |

Attachment: pgpBSOUpve7fc.pgp
Description: PGP signature

Reply to: