[dpl-helpers] draft release team delegation
Adam D. Barratt
adam at adam-barratt.org.uk
Sat Dec 14 19:32:28 UTC 2013
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
More information about the DPL-helpers
mailing list