(→Which changes are accepted into Branch) |
|||
| (5 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
== Branching phase == | == Branching phase == | ||
The branching phase of the release cycle lasts around 1 month. | The branching phase of the release cycle lasts around 1 month. | ||
| - | === Trunk frozen | + | === Trunk frozen during branching process === |
It begins with a complete Trunk freeze which is enforced during the branching process. This is usually done over a weekend so as not to disrupt development as much as possible. Once the branching is complete, the Trunk and the Branch will be re-open for development. Trunk will begin the 6-month [[Release_Engineering/Release_Timeline#Development_phase|development phase]] again. | It begins with a complete Trunk freeze which is enforced during the branching process. This is usually done over a weekend so as not to disrupt development as much as possible. Once the branching is complete, the Trunk and the Branch will be re-open for development. Trunk will begin the 6-month [[Release_Engineering/Release_Timeline#Development_phase|development phase]] again. | ||
| + | |||
=== Which changes are accepted into Branch === | === Which changes are accepted into Branch === | ||
| - | Only approved blockers targeting the Branch will be accepted into the Branch. The 'blocker' flag in [http://bugs.meego.com bugs.meego.com] exists a few weeks before branching. Anyone can set a feature or bug as a 'proposed' blocker through [http://bugs.meego.com bugs.meego.com]. Release Engineering gathers feedback from Program Management and Development teams as to which bugs should be accepted or rejected. Release Engineering sets bugs to 'accepted' or 'rejected', depending on the feedback given. Again, only approved blockers targeting the Branch will be accepted into the Branch. | + | Only ''approved'' blockers targeting the Branch will be accepted into the Branch. The ''blocker'' flag in [http://bugs.meego.com bugs.meego.com] exists a few weeks before branching. |
| + | |||
| + | Anyone can set a feature or bug as a ''proposed'' blocker through [http://bugs.meego.com bugs.meego.com]. Within the bug, state your case as to why you believe this bug should be a blocker for 1.2. | ||
| + | |||
| + | Release Engineering gathers feedback from Program Management and Development teams as to which bugs should be ''accepted'' or ''rejected''. Release Engineering sets bugs to ''accepted'' or ''rejected'', depending on the feedback given. | ||
| + | |||
| + | Again, only ''approved'' blockers targeting the Branch will be accepted into the Branch. | ||
| + | |||
=== How to submit a bug-fix into the Branch === | === How to submit a bug-fix into the Branch === | ||
| - | In order for a Meego core bug-fix to be accepted into a Branch, it needs to be submitted to BOTH the Meego Trunk and the Meego Branch. This will ensure that the bug-fix that was accepted into the Branch will also be available in the Trunk. The exception are, of course | + | In order for a Meego core bug-fix to be accepted into a Branch, it needs to be submitted to BOTH the Meego Trunk and the Meego Branch. This will ensure that the bug-fix that was accepted into the Branch will also be available in the Trunk. |
| + | |||
| + | The exception are, of course: | ||
| + | |||
| + | * if the package in question does not exist in Trunk | ||
| + | * if the package has been upgraded in Trunk, thus already absorbing the bug-fix in question. | ||
| + | |||
=== Setting your home: and devel: OBS projects to build against Branch === | === Setting your home: and devel: OBS projects to build against Branch === | ||
Don't forget to set your development OBS projects on [http://build.meego.com build.meego.com] to build against the new Branch before submitting your bug fixes to the Branch. Go here to find out how: [[Release_Engineering/Repo_List|MeeGo Repos]]. | Don't forget to set your development OBS projects on [http://build.meego.com build.meego.com] to build against the new Branch before submitting your bug fixes to the Branch. Go here to find out how: [[Release_Engineering/Repo_List|MeeGo Repos]]. | ||
[[Category:Release engineering]] | [[Category:Release engineering]] | ||
Contents |
The branching phase of the release cycle lasts around 1 month.
It begins with a complete Trunk freeze which is enforced during the branching process. This is usually done over a weekend so as not to disrupt development as much as possible. Once the branching is complete, the Trunk and the Branch will be re-open for development. Trunk will begin the 6-month development phase again.
Only approved blockers targeting the Branch will be accepted into the Branch. The blocker flag in bugs.meego.com exists a few weeks before branching.
Anyone can set a feature or bug as a proposed blocker through bugs.meego.com. Within the bug, state your case as to why you believe this bug should be a blocker for 1.2.
Release Engineering gathers feedback from Program Management and Development teams as to which bugs should be accepted or rejected. Release Engineering sets bugs to accepted or rejected, depending on the feedback given.
Again, only approved blockers targeting the Branch will be accepted into the Branch.
In order for a Meego core bug-fix to be accepted into a Branch, it needs to be submitted to BOTH the Meego Trunk and the Meego Branch. This will ensure that the bug-fix that was accepted into the Branch will also be available in the Trunk.
The exception are, of course:
Don't forget to set your development OBS projects on build.meego.com to build against the new Branch before submitting your bug fixes to the Branch. Go here to find out how: MeeGo Repos.