Open Stack

Based on discussions going back to the Liberty feature freeze, we have
decided to add some additional deadlines for Mitaka, to avoid having 
fire drills at the end of the release, and to focus core reviewer 
attention on the right things.

As always, we will enforce a Feature Freeze on the M-3 milestone date: 
March 3rd [1]. Only bugfixes and documentation changes are allowed to 
merge after that date without an explicit feature freeze exception (FFE).

Also like before, we will enforce a feature proposal freeze 2 weeks 
before the feature freeze, on Feb 18th. New feature patches must be 
submitted to gerrit, with complete test coverage, and passing Jenkins by 
this date.

A new deadline for Mitaka will be that new drivers must be submitted 3 
weeks before the feature freeze, by Feb 11th, with the same requirements 
as above, and working CI. This additional deadline was deemed necessary 
due to the extra amount of work required to review new drivers. 
Additionally driver refactor patches (any patch that significantly 
reworks existing driver code) will be subject to the same deadline, 
because these patches tend to take as much resources to review as a 
whole new driver.

Lastly and most importantly, we're going to enforce a deadline for 
"large" new features. They must be submitted to gerrit 6 weeks before 
the feature freeze, by Jan 21 (same date as M-2 milestone [1]). The goal 
of this deadline is to ensure that significant new functionality has 
time to go through multiple test-review-fix cycles before feature 
freeze. We learned during Liberty that this is essential, and that it 
doesn't work to try to review major new features at the same time we're 
reviewing drivers, bugfixes, and other features.

For the purposes of the above deadline, we decided to define "large" 
features this way [2]:
* If a patch adds 500 mores line than it removes, not counting test 
code, then it is considered large.
* If a patch makes changes to 3 or more of: REST API, DB schema, RPC 
layer, scheduler, and manager, then it is considered large.

I will emphasize that the above rules are not a substitute for human 
judgement, and the core team will make exceptions at our discretion. The 
goal of these rules are to provide guidelines when you should submit 
patches to maximize your chances of getting them into Mitaka.

We can make exceptions to let things in after the deadlines, as needed, 
but more importantly, just meeting the above deadlines doesn't mean your 
patch is guaranteed to get merged. We still recommend submitting things 
well before the deadlines and also socializing your changes as much as 
possible to get buy in and reviews.

-Ben Swartzlander


[1] https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
[2] 
http://eavesdrop.openstack.org/meetings/manila/2015/manila.2015-11-19-15.00.log.html