Differences between revisions 5 and 6
Revision 5 as of 2004-12-27 11:18:11
Size: 963
Editor: anonymous
Comment:
Revision 6 as of 2004-12-27 16:38:44
Size: 1381
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:

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

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

1. Announce the freeze date, and the length of freeze period right when a stable have been pushed out. 2. At the freeze date drop all packages which do not meet QA goals. 3. At the end of the freeze period, release. 4. Be very consistent, do not allow delay in the above. 5. Make the period between stable releases much shorter.

Pros:

  • Maintainers would be more strongly motivated: they would know that they package will be dropped if they do not fix
  • Shorter release periods would allow for better planning for packages

Cons:

  • Some packages would missing from stable
  • Some packages must be in stable. Dropping packages such as apache, glibc, postgresql, vim, emacs21 would be unacceptable.

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