Fedora Release Criteria: Difference between revisions

Latest revision as of 00:12, 12 October 2017

In other languages: English (en) español (es) [edit]

You can't know if you're ready to release unless you know what done means.

....

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 release 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.

Johanna Rothman

Criteria for Current Release Milestones

Basic Release Criteria
Fedora 42 - Beta, Final

Purpose

The release criteria aim to:

Clearly specify the criteria that must be met for each of our public releases (nightly composes, Beta and Final) to ship
Document all the requirements of our target audience for each Fedora release
- The target audiences for each public release (nightly composes, Beta and Final) can be different, and may overlap
- The criteria at any given time are not set in stone: there may be requirements that have been overlooked, or that are new, and in these cases, the criteria should be expanded to ensure all needs are covered
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

Benefits

Having a consistent, public and comprehensive set of release criteria should:

Reduce the need for meetings to be held and subjective decisions made at the last minute
Help 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
Help 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
Provide an early warning sign if the release is not on track for shipping on time
Make it clear whether a given bug should block the finalization of a release

Release Constraints

Fedora places a high priority on releasing according to schedule. While release quality is very important, there are circumstances where the schedule takes priority.

The following priorities, in this order, will define what matters most in completing our releases:

Target schedule date
Release quality
New release features

Bugs can be fixed in package updates and new features can be included in the next release.

Basic Release Criteria

The Basic Release Criteria have a similar purpose to the Beta and Final release criteria. However, they apply to all Rawhide and Branched nightly composes (as well as all milestone candidate composes). We aim to ensure every nightly compose that is released - in the sense of being synced to the rawhide repository or the Branched fedora repository - meets the Basic Release Criteria, using a fully automated process (both the testing and the determination as to whether a compose should be released are automated). The Basic Release Criteria are based on the former Alpha Release Criteria.

Reference Material

@@ 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.}}
+{{autolang|en|es|base=yes}}
-{| border="1px #222222" cellpadding="0" cellspacing="0" align="center" width="90%" style="background-color:#EEEEEE;"
+{{Quote|You can't know if you're ready to release unless you know what ''done'' means.<br>
-|-
-| <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>
 ....<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 release 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.|[http://www.universityalliance.com/info1/whitepapers/villanova/pdfs/WP_VU_ReleaseCriteriaGoodtoGo.pdf Johanna Rothman]}}
+== Criteria for Current Release Milestones ==
+* [[Basic Release Criteria]]
+* Fedora {{FedoraVersionNumber|next}} - [[Fedora {{FedoraVersionNumber|next}} Beta Release Criteria|Beta]], [[Fedora {{FedoraVersionNumber|next}} Final Release Criteria|Final]]
-<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>
 == Purpose ==
-* To make sure our releases meet the needs of our target audience.
+The release criteria aim to:
-** 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.
+* Clearly specify the criteria that ''must'' be met for each of our public releases (nightly composes, Beta and Final) to ship
-* The clearly document the criteria that ''must'' be met for each of our public releases (Alpha, Beta, Final) to ship.
+* Document all the requirements of our target audience for each Fedora release
+** The target audiences for each public release (nightly composes, Beta and Final) can be different, and may overlap
+** The criteria at any given time are not set in stone: there may be requirements that have been overlooked, or that are new, and in these cases, the criteria should be expanded to ensure all needs are covered
+* 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
 == 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 ==
+Having a consistent, public and comprehensive set of release criteria should:
-* 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 ==
+* Reduce the need for meetings to be held and subjective decisions made at the last minute
-* [[Fedora_13_Alpha_Release_Criteria |Fedora 13 Alpha Release Criteria]]
+* Help others who are not involved in the release process to understand our goals and objectives
-* [[Fedora_13_Beta_Release_Criteria |Fedora 13 Beta Release Criteria]]
+* Reduce the need for "gut level" subjective feelings about whether we are ready to ship or not
-* [[Fedora_13_Final_Release_Criteria |Fedora 13 Final Release Criteria]]
+* Help 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
+* Provide an early warning sign if the release is not on track for shipping on time
+* Make it clear whether a given bug should block the finalization of a release
 == 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.
+Fedora places a high priority on releasing according to schedule.  While release quality is very important, there are circumstances where the schedule takes priority.
 The following priorities, in this order, will define what matters most in completing our releases:
@@ Line 44: / Line 41: @@
 Bugs can be fixed in package updates and new features can be included in the next release.
+== Basic Release Criteria ==
+The [[Basic Release Criteria]] have a similar purpose to the Beta and Final release criteria. However, they apply to all Rawhide and Branched nightly composes (as well as all milestone candidate composes). We aim to ensure every nightly compose that is released - in the sense of being synced to the [[Repositories#The_rawhide_repository|''rawhide'' repository]] or the [[Repositories#The_fedora_repository_in_Branched_releases|Branched ''fedora'' repository]] - meets the Basic Release Criteria, using a fully automated process (both the testing and the determination as to whether a compose should be released are automated). The Basic Release Criteria are based on the former Alpha Release Criteria.
 == Reference Material ==
@@ Line 50: / Line 51: @@
 * http://www.jrothman.com/Papers/releasecriteria.html
 * http://www.ddj.com/architect/184415651
+[[Category:Release Criteria]]

Search