Re: Delegation for the Release Team
Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
> On 06/01/14 at 11:56 +0000, Neil McGovern wrote:
> > Explicitly again: Please see the last 7 years worth of bits mails, where
> > the release team have lowered this without advance notice, for BSPs etc.
...
> First, I do not think that we have a NMU *policy*. What we have is a set
> of (non-binding) recommended procedures, including recommended delays,
I think regarding our NMU policy as non-binding is a very bad idea.
NMUs are an important area of interaction between maintainers and
other contributors. Given the social contest, I think it is very
important that we have a clear understanding of what kind of NMU is
permissible when. Anything else is a recipe for people with different
understandings of the rules to end up arguing.
Can you imagine the reaction of a maintainer team if an NMUer
justified a breach of the policy on the grounds that it's not binding
but only "guidelines" ? I think the reaction here on -devel would be
unfavourable too.
> I think that this part of developers-reference, like any part of
> dev-ref, can be changed by any DD, following a process similar to the
> one the release team used in 2011:
> > - the release team announced its intention to change the policy in
> > https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html
> > - #625449 was filed against developers-reference
> > - there was some discussion
> > - the proposed change made it into developers-reference
This is obviously impractical, for, for example, a BSP.
> That is, propose a change and seek consensus.
Given Lucas's attitude, I would like to suggest to the release team
that they file a bug against the the Developers' Reference, containing
a proposed change explicitly authorising the release team to vary the
NMU rules. That ought to satisfy Lucas's idea of the proper process
and put us back to the status quo ante.
Ian.
Reply to: