[dpl-helpers] draft release team delegation

[Adam D. Barratt]

On Thu, 2013-12-12 at 06:49 +0100, Lucas Nussbaum wrote:
> It is my great pleasure and honor to officialize the existence and the
> powers of one of Debian's most important teams: the Release Team.
> 
> I'd like to stress that the delegation (below, between dashed lines) does
> _not_ include "get the release in shape by fixing all RC bugs": that stays
> the collective responsibility of the Project as a whole!
> 
> Internally, the release team distinguishes between:
>  - Release Managers -- RM: Adam D. Barratt, Niels Thykier;
>  - Stable Release Managers -- SRM: Philipp Kern;

For the record, there's officially two SRMs. :-)

>  - Release Assistants -- RA: Andreas Barth, Felipe Augusto van de Wiel,
>    Ivo De Decker, Julien Cristau, Jonathan Wiltshire, Cyril Brulebois,
>    Mehdi Dogguy.
> This distinction is not relevant in terms of delegated powers.
[...]
> The Release Team oversees and manages the releases of the testing,
> stable, and oldstable distributions (aka suites).
> 
>  * Release Team members decide on the release schedule (e.g.; freeze date,
>    release date)

This reads (at least imho) as though it only refers to the release of
the testing distribution. If that's intentional then I wonder if
additional items relating to (old)stable point releases should be
included; if not then maybe we could clarify the wording here.

>  * Release Team members define the content of those suites, that is:

s/those/the listed/ or similar? This point is a little away from the
list of suites already (although closer than it was when I originally
had this thought on an earlier version).

>    + They define the packages that are part (or are not part) of those
>      suites. Generally, that is achieved:

fwiw, I think the parenthesised section is redundant by definition.

>     - by deciding which issues are release-critical (RC) -- making the
>        affected packages not suitable for stable releases -- usually by
>        setting the corresponding bug's severity to serious, grave or
>        critical;
>      - by deciding which package modifications (e.g.; bugfixes) are
>        suitable for inclusion in those suites;
>      - by deciding when and how updated packages migrate between suites.
>        When necessary, they may temporarily forbid specific uploads to
>        unstable in order to facilitate transitions.

I guess this latter point implicitly covers point releases.

>    + They define the ports (architectures) that are part of those suites,
>      by deciding which issues are severe-enough to prevent a port from
>      inclusion in a stable release.

s/severe-enough/severe enough/. I'd be tempted to s/inclusion/being
included/ or even "being part of a stable release" too.

>  * Release Team members decide on the codenames for stable releases.
> 
>  * Release Team members coordinate the work on the release notes, and
>    have the final say on their content.
> 
>  * Release Team members have the final say on the official material
>    for each release (e.g., they decide which CD images are official
>    ones).
> 
> Policy decisions by the Release Team (on packages, on architectures) are
> expected to rely on well-defined processes and criterias.

I realise this point is being removed, but as a note, criteria is a
plural noun; one can't have criterias. :-)

As Neil mentioned, I do wonder if release goals should be mentioned
somewhere. I know that we've had the discussion about (possibly|
probably) not managing them in future, but it is still current practice
that we do.

Regards,

Adam