(→Which changes are accepted into Branch) |
(→Which changes are accepted into Branch) |
||
| Line 5: | Line 5: | ||
=== 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]. 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 | + | 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 === | ||
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.