Candidate Quality Election

The traditional release process in the Commons is as follows:

• cut release candidate
• announce release candidate on user and dev lists
• wait a while to see if any issues are reported
• VOTE on the release
• cut release
  

This has many advantages. However, the actual release is never tested and the testing period is short. Components with large numbers of downstream users may like to consider an alternative system that encourages better testing of the actual release cut.

Candidate quality election follows a different pattern. A release is cut and announced as a release candidate. It is then VOTE'd to alpha, beta and full release quantity. Each stage is announced widely and users are encouraged to report any problems. If any issues emerge that must be addressed, a new release is created and the cycle starts again. Developers are recommended to VOTE +1 only if they have tested the release themselves.

The (idealized) process is as follows:

• cut release
• announce release candidate
• promotion to alpha VOTE
• announce alpha release
• promotion to beta VOTE
• announce beta release
• promotion to full release VOTE

The actual release does not change, only the designation and name of the distributions.

This process is longer and more cumbersome but does offer better testing for the actual release.