(Created page with '{{draft | This page is a proposal for Fedora 13. It has not been accepted or officialy reviewed and should not be relied on.}} {| border="0" cellpadding="10" cellspacing="0" al...') |
(Make the box purdy) |
||
Line 1: | Line 1: | ||
{{draft | This page is a proposal for Fedora 13. It has not been accepted or officialy reviewed and should not be relied on.}} | {{draft | This page is a proposal for Fedora 13. It has not been accepted or officialy reviewed and should not be relied on.}} | ||
{| border=" | {| border="1px #222222" cellpadding="0" cellspacing="0" align="center" width="90%" style="background-color:#EEEEEE;" | ||
| | |- | ||
|<blockquote><div style= "font- | | <div style="margin: 1ex 2em 1ex 2em;"><blockquote><div style="font-size:87%; color: #202020;">You can't know if you're ready to release unless you know what ''done'' means.<br> | ||
You can't know if you're ready to release unless you know what ''done'' means.<br> | |||
....<br> | ....<br> | ||
When you use release criteria to know when a project is done, you have taken potentially hidden decisions and made them public and clear. Make your rlease criteria objective and measurable, so everyone on the project knows what they're working towards. Use the criteria as you progress through the project and up to the final release. Then you can say 'Release it!' with pride.</div></blockquote> | When you use release criteria to know when a project is done, you have taken potentially hidden decisions and made them public and clear. Make your rlease criteria objective and measurable, so everyone on the project knows what they're working towards. Use the criteria as you progress through the project and up to the final release. Then you can say 'Release it!' with pride.</div></blockquote> | ||
[http://www.universityalliance.com/info1/whitepapers/villanova/pdfs/WP_VU_ReleaseCriteriaGoodtoGo.pdf Johanna Rothman] | <div style="float: right; margin: 1.5ex 5em 1ex;">[http://www.universityalliance.com/info1/whitepapers/villanova/pdfs/WP_VU_ReleaseCriteriaGoodtoGo.pdf Johanna Rothman]</div></div> | ||
|} | |} | ||
<br> | <br> |
Revision as of 19:52, 2 December 2009
|
Purpose
- To make sure our releases meet the needs of our target audience.
- The target audience for each public release (Alpha, Beta, and Final) can be different. They might also overlap.
- To establish when a release is "done" in terms that most people can understand and in ways that help new people to understand the process and participate.
- The clearly document the criteria that must be met for each of our public releases (Alpha, Beta, Final) to ship.
Benefits
- By documenting and deciding these items in advance we seek to lessen the the last minute meetings and subjective decisions that have to be made at the last minute.
- Help as a guide to others who are not involved in the release process to understand our goals and objectives
- Reduce the need for "gut level" subjective feelings about whether we are ready to ship or not.
- Helps us to focus on the purpose of the release and what we are doing it for while focusing less time and energy on things outside of this scope.
- Provides an early warning sign if the release is not on track for shipping on time.
Release Criteria Specifics
- Release criteria for each public release also provides guidance as to whether a particular bug should block the public availability of a release.
- Release criteria increases in difficulty culminating with the Final Release (GA--General Availability)
- Unique pages for the release criteria are created for each public release
- Release criteria not only reflects acceptable defect levels, it also details acceptable levels of polish
Public Releases
Release Constraints
"You can't have it all." Every software project has constraints and cannot "have it all" or "hold all things equal." Fedora recognizes this and prioritizes these constraints.
The following priorities, in this order, will define what matters most in completing our releases:
- Scheduled date met
- Release quality
- New release features
Fedora values releasing on time and on a set schedule more than it values shipping with less bugs and new features. Bugs can be fixed in package updates and new features can be included in the next release.