Differences between revisions 18 and 21 (spanning 3 versions)
Revision 18 as of 2005-02-06 09:34:45
Size: 2138
Editor: anonymous
Comment:
Revision 21 as of 2009-03-16 03:33:40
Size: 2168
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
 * Some packages must be in the release. Dropping packages such as Apache, glibc, ["PostgreSQL"], VIM, emacs21 is unacceptable.  * Some packages must be in the release. Dropping packages such as Apache, glibc, [[PostgreSQL]], VIM, emacs21 is unacceptable.

This proposal is just an additional control to the QA procedures already in place. It can be used in combination with all other proposals that have the notion of release and quality measures (e.g. lack of RC bugs) related to them.

  • Announce the freeze date and the length of freeze period immediately after a release.
  • At the freeze date drop all packages which do not meet QA goals.
  • At the end of the freeze period, release.
  • Be very consistent, do not allow delay in the above.

Pros:

  • Maintainers would be more strongly motivated: they would know that their package would be dropped if they did not fix it.
  • Shorter release periods would allow for better planning.

Cons:

  • Some packages would be missing from the release.
  • Some packages must be in the release. Dropping packages such as Apache, glibc, PostgreSQL, VIM, emacs21 is unacceptable.

  • Packages can get dropped from the release solely because RC bugs were reported against them at the last minute.
  • This increases the incentive for users NOT to report bugs close to release (for example policy violations).

Opinions: We're already doing this as part of the ReleaseWhenReady strategy, and the fact is that most of the unfixed RC bugs end up in either core packages that we can't drop, or as a steady stream that are filed and fixed against other packages that we can drop, but would rather get a fix for. So I think the unique part of this proposal boils down to be more a FixedReleaseDate than anything else. -- JoeyHess

More widely used packages will tend to have more bugs posted on them, so (my guess is) they will tend to have more RC bugs. But these are exactly the popular packages Debian wants to ship. -- PaulNijjar

We could solve the important package dropping problem by identifying a set of Release Essential (RE) packages. The release would only be permitted when zero RE packages contain RC bugs. The concept of RE packages also provides a mechainsm to formally identify new features deemed critical to a release (eg DI for 3.1). -- StephenBirch

See ReleaseProposals for alternatives.