02: PI open for next MP, this is flexible and will be announced by a RM email to release.management list.
02 - 10: Merge of projects, very big commits, relevant functional or platform changes.
02 - 23 : Normal commits that should be closed within a week.
23 - 31: The last week of the month:
- If you cannot warranty that your issue can be closed next day, do not push it.
- Usage of Try is always highly recommended, during this week Try verification is a Must.
- During this week, like the rest of the month, the integration should never been broken, if the fix of the integration it is not immediate, the issue should be backed out.
31: Last day to push things to pi for enter in the MP, all the issues should be closed at the end of this day.

01 - 02: Integrate pi to main, during this period pi is frozen, until RM email says otherwise.
02: RM package the current main, QA start the testing of the MP. RM will send an email when PI it is open for next MP.
02 - 14 : QA test
14: If needed, RM will do a second package with the regressions found in the QA test.
15: RM publish the MP

If the second day of the month, there are things that are mandatory to enter in the MP but they are not in main, they will be transplanted later, before the 15, and they will not be included in the QA test.
If the there are many things pending at the time of the 1st package, it can be decided to freeze pi.
If on the last day of the month there are issues not closed then a clear reason for this and ways to avoid it next time should be provided by the team.
If the first and/or second day of the month are on weekend, then the package and the publish will be delayed one or two days.

If a issue breaks the integration, in any day of the month, it should be fixed with high priority, if the fix is expected to take some time, it can be decided to backout it.
It is very important to not break the integration as a broken pi also means that all try pushes will be broken by the same problem!

Issues should be closed in less than one week from they were resolved.
All the issues pushed to pi should be closed by end of month, so don't push a issue if cannot be guarantied to be closed at the end of the month.

During QA test, issues found that are blocker for the release should be solved with high priority
During QA test, QA can ask RM to do a repackage if consider necessary to include in the test a commit. If no, on 14 RM will do a repackage if pending things are needed to include in the MP.

RM will send these email reminders:

02: this date it is flexible. pi open for next MP, remind the basic dates of the release (10 is last day for merges, 31 is last day to push).
23: only are accepted commits that have warranty of been closed for the next day.

Retail release

Note: The publish and unfreeze of repos will be done as soon as QA test finish, so not need for wait till 1 for do the publish.

This page has been accessed 1,530 times. This page was last modified on 12 June 2013, at 10:09. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.

Release Policy