[dpl-helpers] draft release team delegation

[Neil McGovern]

On Thu, Dec 12, 2013 at 11:29:43PM +0100, Lucas Nussbaum wrote:
> On 12/12/13 at 16:14 +0000, Neil McGovern wrote:
> > > > 2) Setting the NMU delay policy
> > > 
> > > I don't think that this should be part of the release team's delegated
> > > powers. I feel that the NMU procedures are already open enough, as I
> > > argued in https://lists.debian.org/debian-devel/2013/12/msg00011.html .
> > > Could you follow-up in that thread, maybe?
> > > 
> > 
> > It has, however, been so, see dev-ref 5.11.1 and #625449, particularly
> > message 90. I know you don't agree with this, but if you wish to
> > essentially remove the current practice, then I think that this needs
> > much more explicit statement in the mail.
> 
> OTOH, in #625449, the release team did not _decide_ on a new NMU policy.
> Instead, the team announced its intention to change the policy in
> https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html,
> then filed a bug against dev-ref, then argued a bit in the bug, then the
> topic was raised on -devel@, and as a result, the policy was changed.
> That's a very reasonable way to make such changes, that does not require
> any delegated power.
> 

Indeed, but see the last 7 years worth of bits mails, where the release
team have lowered this without advance notice, for BSPs etc.

> > Perhaps something like:
> > Note - this does not include the practice that the release team may set
> > rules for NMU delays. Instead, this will be handled by [dev-ref
> > maintainers/policy/ftp-masters/someone else].
> > 
> > Personally though, I would oppose the removal of this de-facto state.
> 
> Why do you feel that it is so important for the release team to have
> that power?
> 

Because it gets RC bugs fixed quicker, so we can release quicker.

> Other opinions on this?
> 
> I would also like to argue that, in terms of scope, this is quite far
> from the other powers of the release team, as it would deal with general
> package uploads to unstable (even if not said explicitely). I wouldn't
> mind so much if this was about NMUs to t-p-u (but I know there are good
> reasons not to use t-p-u too much).
>  

Yes, but the concept that these suites exist independently, or that
we're actually running three different "releases" is, in my view,
misguided. This is the one of the core issues which lengthens the time
it takes for a new release to be made - the idea that actions in
unstable don't affect the next release, or the other way around.

Essentially - siloing the release team to just testing and stable will
harm the project's ability to release overall. This has been the
fundamental problem with attempting to create a delegation in the past -
the efforts of the team cross so many different areas that constraining
them into a technical strand is very difficult, and for obvious reasons,
a delegation that says "whatever the release team need to do to get the
release out" isn't palatable :)

Additionally - my main point is a procedural one - the initial
delegation should document what is current practice, and then should be
amended later if you feel you wish to change the scope of the
delegation. Delegating a subset of current practice, without being
explicit about is opaque.

Neil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/dpl-helpers/attachments/20131213/ca2f2f85/attachment.sig>