Re: Delegation for the Release Team
On 06/01/14 at 12:59 +0000, Ian Jackson wrote:
> 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 agree with you that the NMU recommended practices must be clear, and
leave little place for interpretation. I think that [1] is reasonably
clear in terms of what's generally considered acceptable or not, even
though there's always place for improvement.
[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu
I disagree that we should have *rules* because, given the social
context, I find it important to leave space to adapt to each case.
For example, if I had a fix for #713183 (RC bug against pyg, opened
on 2013-06-22, no action since then, no co-maintainer, maintainer
looks inactive, popcon=3), I wouldn't have a problem uploading with
a 0-day delay.
If I thought I had a fix for #727786 (RC bug against eglibc, opened
on 2013-10-26, last action on 2013-11-12, maintained by an active
team, popcon=158880), I don't think that uploading with a 0-day delay
would be a very good idea.
Problem is, there are many cases between those extremes. If you turn the
NMU recommended practices into rules, you could create or reinforce the
feeling that 0-day NMUs are a perfectly valid option in both cases
described above.
> > 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.
Do you see a problem with the current NMU recommended practices, that
you would like to fix? I'm asking because the current ones have been
defined 2.5 years ago, and I don't remember much discussion about them
since then. Maybe we could save everybody's time, and have that
discussion about who is allowed to change them when there's a change
that someone wants to do.
Also, I'm surprised that you didn't comment on the last part of my mail.
Lucas
Reply to: