[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)

On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote:
> On 28/11/13 at 21:04 +0100, Niels Thykier wrote:
> > Release Goals
> > =============
> > 
> > We discussed release goals in some depth at the recent sprint.
> > 
> > The general consensus was that, whilst release goals have been useful
> > in the past to introduce archive-wide changes, we should review
> > whether this remains the case and whether the release team is really
> > the right place to determine them. We intend to consult with the
> > project on this point in due course.

> Indeed. To elaborate a bit more:

> Release Goals are usually distribution-wide changes to Debian. We have had
> release goals for a long time (see e.g. [1] about etch release goals, in 
> 2006). Release Goals seem to have several purposes:

> - in the past, specific NMU rules applied to release goals. However, that
>   is no longer the case. It is already possible to NMU for any bug (including
>   wishlist ones) provided that reasonable advance notice and effort to
>   consult the maintainer is applied.

I think that misstates the rationale for release goals.  It was *always*
possible to NMU for any bug "provided reasonable advanced notice and
consultation".  The point of declaring a release goal is that, for a
distribution-wide change that touches many packages, following the standard
SRU process where each upload requires a built-in waiting period
significantly slows down progress.  So having a relaxed NMU policy for
recognized project-wide goals, allowing release goal NMUs to be done quickly
as part of bug squashing parties, benefits the project by letting us reach
these goals much more effectively.

> - Release Goals kind-of define Debian's technical agenda. However, one could
>   question whether it's really the role of the release team to decide on
>   this, rather than the one of the project at large. Shouldn't this be
>   discussed the usual Debian way (= discussion on mailing list to gather 
>   feedback and reach consensus on the global picture; then do-ocracy for
>   the smaller implementation details)?

We're not talking about small implementation details.  What do you propose
as a mechanism for agreeing to a reduced NMU delay for archive-wide changes?
The release team may not be the right way to get this done organizationally,
but a strict consensus-driven process on debian-devel is also not realistic
as we will never converge on a decision in a reasonable amount of time.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: