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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129100255.ga19...@xanadu.blop.info