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.
Comments?
Lucas
[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: