[dpl-helpers] draft release team delegation
Lucas Nussbaum
leader at debian.org
Thu Dec 12 05:49:11 UTC 2013
Hi,
On 11/12/13 at 19:03 +0000, Neil McGovern wrote:
> Hi Lucas,
>
> On Wed, Dec 11, 2013 at 06:57:39PM +0100, Lucas Nussbaum wrote:
> > Please find below a draft delegation for the release team.
> >
> > Could you please review it and send feedback (or ACKs) before
> > 2013-12-16?
> >
>
> [...]
>
> > Release Team delegation
> > =======================
> >
> > I hereby appoint the following developers as Release Team members:
> >
> > - Adam D. Barratt <adsb> (release manager)
> > - Niels Thykier <nthykier> (release manager)
> > - Philipp Kern <pkern> (stable release manager)
> > - Andreas Barth <aba> (release assistant)
> > - Felipe Augusto van de Wiel <faw> (release assistant)
> > - Ivo De Decker <ivodd> (release assistant)
> > - Julien Cristau <jcristau> (release assistant)
> > - Jonathan Wiltshire <jmw> (release assistant)
> > - Cyril Brulebois <kibi> (release assistant)
> > - Mehdi Dogguy <mehdi> (release assistant)
> >
>
> Similarly to FTP-masters, I would advise not adding in release
> assistants, but just delegating release managers as...
>
> > The distinction between release managers, stable release managers and
> > release assistants is not relevant in terms of delegated powers, but is in
> > terms of internal team organization and decision-making processes.
> >
>
> ... this should either be documented in the delegation, or left out. And
> if it's documented in the delegation, then there's a issue when the team
> want to change how they work internally.
I don't feel very strongly about this, but:
1) I would prefer to delegate all RM + RA, as my undestanding of the
RT's inner workings is that RA use the delegated powers directly,
without necessarily consulting with the RM.
2) For documentation purposes, I think that it's useful to state who is
RM/SRM/RA in the delegation email. However, it's true that this could be
left out of the official part. Doing that in the updated draft below.
> > The Release Team oversees and manages the releases of the testing,
> > stable, and oldstable distributions (aka suites).
> >
> [...]
> > by deciding with issues are release-critical (RC)
> *which
>
> It's also missing a few areas:
> 1) Allowing important severities to be set for release goals, or other
> items.
I don't think that this is necessary, both because the release goals
process is in an unclear state, and because severity=important is just a
tag (there are no consequences).
> 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?
> 3) Defining what consititutes a Debian release beyond the suites - eg:
> ability to say that "x is the official Debian Live CD image"
Good point.
I propose adding:
* Release Team members have the final say on the official material
for each release (e.g., they decide which CD images are official
ones).
Thanks for the feedback. Updated draft below.
Lucas
====================================================================>8
Subject: Delegation for the Release Team
Hi,
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;
- 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.
- Lucas
----------------------------------------------------------------
Release Team delegation
=======================
I hereby appoint the following developers as Release Team members:
- Andreas Barth <aba>
- Adam D. Barratt <adsb>
- Felipe Augusto van de Wiel <faw>
- Ivo De Decker <ivodd>
- Julien Cristau <jcristau>
- Jonathan Wiltshire <jmw>
- Cyril Brulebois <kibi>
- Mehdi Dogguy <mehdi>
- Niels Thykier <nthykier>
- Philipp Kern <pkern>
The delegation is not time-limited. It will be effective until
further changes by present or future DPLs.
Task Description
----------------
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)
* Release Team members define the content of those suites, that is:
+ They define the packages that are part (or are not part) of those
suites. Generally, that is achieved:
- 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.
+ 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.
* 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.
----------------------------------------------------------------
More information about the DPL-helpers
mailing list