On Mon, 6 Jan 2014 12:26:14 -0500 Michael Gilbert <mgilb...@debian.org> wrote:
> On Mon, Jan 6, 2014 at 7:59 AM, 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.
+1
> > 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.
>
> Additional layers of bureaucracy and inflexibility are the opposite
> direction that the project should be going in.
The project needs to respect the work of hard pressed teams and *help*
those teams by having strict and clear rules. Wasting time arguing
about requirements which are too vague or flexible is the wrong
direction if you actually want teams to get anything done other than
answering questions on mailing lists and IRC.
Little makes teams less popular than saying "no" continuously, so make
the rules clear and let the team manage the rules themselves.
The main changes made to the NMU policy by the release team have been
to *reduce* the timeframes but that doesn't mean that the policy itself
should be non-binding.
> > 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.
>
> That is already effectively "enforced" by public shaming (mostly by
> the release team).
Such enforcement is clearly insufficient.
I'm in favour of an NMU policy which pushes non-compliant NMUs to the
appropriate delayed queues automatically. Policy details to be specified
by the release team alone, managed automatically and without room for
"negotiation" (hassle) in order to free the team to actually get the
release into a good state.
NMU Policy must respond to the needs of the project through the whole
release cycle. That means letting the release team reduce the delays
needed before an NMU during a release freeze.
> It would be nice if those engaged in that
> enforcement were more kind. A simple tip to devref would be most of
> the time effective.
Try working with a team who spend most of their time telling people not
to do things. Too many people think being "kind" is equivalent to
"giving way" and take that as a hint to pester continuously "because
the initial response didn't actually say no categorically".
Developers shouldn't *need* to be pointed at the developer reference or
release team announcement emails.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
