|
|
| (3 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{admon/tip|Ignoring the Freeze Process|Ignoring the branch freeze process and introducing new unstable changes to packages anyway can result in your package changes being reverted or reduce the chances of receiving positive karma}}
| | #REDIRECT [[Updates_Policy]] |
| | |
| = Overview =
| |
| At the Branch Freeze event, all packages are branched from <code>master</code> in source control. This is to allow the branched tree to stabilize and enter a bug-fix and polish phase of development. Builds from the branch that are deemed stable will be published into their own repo on the mirrors beside rawhide. Builds from <code>master</code> will continue to be published to the rawhide repo and is open for changes targeting the Fedora release after the one just branched.
| |
| | |
| The Branch Freeze lasts until the branched Fedora is released. At that time the normal package update process takes over.
| |
| | |
| For each release phase after branching - Alpha, Beta, and Final - there is a further, short freeze marked on the schedule as the ''Change Deadline''. Between this point and the relevant release, builds can be submitted to <code>updates-testing</code> according to this policy, but most builds will not be moved from there to '''stable''' until the freeze is over. Note the freeze lifts once the decision to release is made, i.e. usually a few days before the scheduled release date. Only builds that fix blocker or NTH (Nice-To-Have) bugs can be moved to '''stable''' during these harder freezes. The [[QA:SOP_blocker_bug_process]] and the [[QA:SOP_nth_bug_process]] explain how blocker and NTH bugs are defined, nominated and evaluated: if you believe an update for a package of yours should be pushed to '''stable''' after a ''Change Deadline'', please follow one of these processes.
| |
| | |
| The purpose of the Branch Freeze is not to strangle changes, the purpose is to provide a facility to test changes before they are pushed to '''stable''' and allow more meaningful decisions to be made about the risk/reward of the changes.
| |
| | |
| == Getting a build marked Stable ==
| |
| In order for a build from the branch to be deemed '''stable''', it will have to pass through [[Bodhi]]. This process is much like the process of submitting updates to an already released Fedora. Builds that are submitted for testing for the branched Fedora will be published to an <code>updates-testing</code> repo where they can be reviewed and tested by peers. Feedback will be made via bodhi karma and/or bugzilla bugs. Once a maintainer feels their build has received enough feedback and testing, the build can be pushed to '''stable''', where it will be published to the branched Fedora repo and will be considered "in the release". Packages can be pushed to stable once they fulfil [[Updates_Policy#All_other_updates|update criteria]]. The maintainer can specify a positive karma threshold for automatic pushing if desired: once the package reaches this threshold, as long as the minimum requirements under the [[Updates_Policy]] are also met, the package will be automatically pushed stable.
| |
| | |
| == Critical Path Packages ==
| |
| Packages which are in the [[Critical_Path_Packages|Critical Path]] broadly follow the same process, but have stricter minimum requirements, as stated in the [[Updates_Policy#Updates_to_.27critical_path.27_packages|Updates policy]].
| |
| | |
| == New Packages ==
| |
| New packages can still be reviewed, added in source control and built. In order to get them into the '''stable''' branched repo, they will need to go through bodhi as outlined above.
| |
| | |
| = Getting a build past the Freeze =
| |
| If you believe there is a good reason for you to break the branch freeze, you must request an update in bodhi.
| |
| <ol><li>Build and test your package before submitting anything.
| |
| {{admon/important|Build and test first!| Do not omit this step.}}</li>
| |
| <li>Submit the update request by following [[Package_update_HOWTO#Packages_in_the_stable_branches|Package Update HOWTO]]. Please include the following details in the bodhi update information:
| |
| * A description of the change
| |
| * Rationale for why the change is important enough to be allowed in after the freeze
| |
| * Any bugs related to the change
| |
| </li></ol>
| |
| | |
| Once you've submitted the update and requested a push to <code>updates-testing</code>, your build will be published at the next updates push and made available in <code>updates-testing</code> for the branched Fedora.
| |
| | |
| Note that while we use the same tool (bodhi) for filing updates before and after the final release, the strategies for updates should be a bit different:
| |
| * Before the release, it has a lot of advantages to file individual updates for each bug-fix, to make it easier to verify fixes and track regressions
| |
| * After the release, we generally prefer to bundle multiple fixes into a single update to avoid flooding our users with a constant stream of updates, and also to allow some time to test the updates before they are released
| |
| | |
| == Evaluating requests for exception ==
| |
| The consumers of updates-testing for the branched Fedora will evaluate your update and provide feedback.
| |
| * Approval comes in the form of positive karma in bodhi.
| |
| * 3 or more net positive karma is generally desired before pushing to '''stable'''.
| |
| ** If your package is in the [[Critical_Path_Packages|Critical Path]] 1 net positive karma from Proven Testers plus an additional net positive karma from anybody is required
| |
| * If there is negative feedback, work with the tester and a new build may be needed.
| |
| | |
| If your update is accepted and you request a push to '''stable''', your package will be tagged for inclusion the branched release.
| |
| | |
| If your update is withdrawn, your package will not appear in the branched release.
| |
| | |
| | |
| [[Category:Release Engineering]]
| |
