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

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

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.

- in the past, uploads fixing release goals bugs were allowed during freeze.
  However, at this point, it is not clear whether this will be the case for
  jessie. It would be better to aim for fixing all release goals bugs before
  the freeze, and do a shorter freeze.

- 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)?

I personnally think that we should give up on the release goals process in its
current form, and instead advertise recommended practices, built on the
existing recommended practices for mass-bug filings[2], such as:
- aim for a consensus-building discussion on -devel@
- provide a clear plan of what you are trying to achieve (with rationale, 
  evaluation of impact, etc.) (using a wiki page or another type of structured
  document is a good idea)
- provide objectives that are S.M.A.R.T[3] (specific, measurable, attainable, 
  relevant and time-bound), so that it's easy to understand where you want
  to go.
- use usertags to track progress
- etc.

If there is consensus that a given change and its implementation is desired by 
the project, I don't see what some validation from the release team would add.
And if some maintainers refuse to integrate patches for a consensual change, 
we already have existing processes, such as bringing issues to the TC.



[1] https://lists.debian.org/debian-devel-announce/2006/07/msg00005.html
[2] http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#submit-many-bugs
[3] http://en.wikipedia.org/wiki/SMART_criteria

Reply to: