Re: On RCness and the use of the BTS, etc
(Again, I'm following up only to -project.)
Anthony Towns writes ("On RCness and the use of the BTS, etc"):
> On Mon, Nov 11, 2002 at 02:36:44PM -0500, Branden Robinson wrote:
> > * The current imperfection of the Debian Policy Manual causes us to lend
> > more gravity to certain bugs, as a result of "a severe violation of
> > Debian policy (that is, it violates a "must" or "required"
> > directive)," than they deserve.
>
> No, this isn't the case. The "requirements" of the policy manual are
> what has previously been called "release goals" -- they're the things
> that we're insisting we achieve before we'll release. The gravity we
> lend to issues from the policy manual are entirely due to this, and one
> of our release goals is FHS compliance, in every single way.
I disagree most strongly with this paragraph. Perhaps this is the
root of some of the disagreements.
Firstly, I have a very strong disagreement with the whole concept of
`release goals': ie, criteria for a whole-system release that are not
directly related to whether the release works, is better than the
previous one, etc. `Release goals' lead to artificial and pointless
delay in releases, and the `benefit' of stressing maintainers out
until they do something that someone else is keen on is not `worth'
holding the whole distribution to ransom.
But even so, if we are going to have `release goals' - things we will
not release without - then they are specified by the release manager,
not by the policy manual. The policy manual can at best encapsulate
the guidelines the RM will be using (which the RM may have written
themselves, or which may have been decided some other way).
So the policy manual can't say that a bug is definitely RC, unless the
RM says so. But the current process for editing the policy manual
lets pretty much anyone put MUSTs etc. in, which the RM will duly
ignore.
Ian.
Reply to: