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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
