Differences between revisions 1 and 13 (spanning 12 versions)
Revision 1 as of 2004-12-27 06:03:16
Size: 851
Editor: anonymous
Comment:
Revision 13 as of 2005-01-04 09:41:10
Size: 1538
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
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.
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.
Line 7: Line 8:
1. Announce the freeze date, and the length of freeze period right when a stable have been pushed out. 1. Announce the freeze date and the length of freeze period immediately after a release.
Line 9: Line 11:
Line 10: Line 13:
Line 11: Line 15:
5. Make the period between stable releases much shorter.
Line 13: Line 16:
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
}}}
5. Make the period between releases much shorter.
Line 18: Line 18:
Cons:{{{
 * Some packages would missing from stable
}}}
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.

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

See ReleaseProposals for alternatives.

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.

1. Announce the freeze date and the length of freeze period immediately after a release.

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 releases much shorter.

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.

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

See ReleaseProposals for alternatives.