Hi all!
This is an update to our processes based on what we discussed during the PTG.
(1) Queens cycle priorities
We realized that we took too much on ourselves during the Pike cycle. We also
realized that it ended up with a (false) perception that the priorities list is
our complete backlog, and what is out of it is out of the release.
This time we took less work overall, and less feature work in particular, to
address both these issues. So while reviewing the priorities, please keep in
mind that it is not the complete feature set we expect in Queens, but rather
what we will consider our key achievements.
Finally, a big part of the priorities were picked by a voting on the PTG. This,
of course, missed a lot of contributors, and we definitely do not mean to
exclude them. So, please check the discussion notes at
https://etherpad.openstack.org/p/ironic-queens-ptg-open-discussion and let us
know if you think your vote(s) and/or opinion(s) would change the list.
Please leave your comments on the review: https://review.openstack.org/505173. I
would really appreciate if you could do it by next Monday, especially if you
have objections. Note that it's mandatory for all cores to vote!
(2) Weekly priorities update
We definitely liked setting weekly review priorities every team meeting. A
common complain, however, was that this usually excluded vendor work and
subteam-specific patches. By subteams here I mean bifrost, ironic-inspector,
sushy, etc (but not ironic-python-agent, or python-ironicclient, or any
unofficial project).
We decided to address it in a straightforward way. In addition to our regular
weekly priorities we will accept exactly one patch from each supported driver
vendor and one from each vendor subteam. The only condition is to put them there
*before* the meeting, especially if you cannot attend it.
I have updated the whiteboard with a template (see "This Week's Priorities"),
please do populate it before next Monday's meeting.
An important note: a requirement on exactly one patch does not mean we will not
review any other patches from the same vendor that week. It only and solely
means that we will consider only one patch *a priority*.
(3) Release schedule update
To address the difficulties we had with releasing in Pike, we decided the
following:
a) We will finally stick to a release-often cadence. You can expect intermediary
ironic releases roughly every months. This is to make sure we constantly keep
the code base in a releasable form, instead of urgently cleaning it up in the
end of the cycle.
b) This, in turn, has two consequences. We have to be ready to land incomplete
features, so we should take care to not expose something non-working to users or
operators. And we have to do release notes right from the first attempt, in the
worst case in a follow-up.
c) To avoid issues with grenade in the end of the cycle, we will branch
stable/queens at the same time as the other projects - on the RC1 week. Features
not landed before that point will be out of the release.
d) To give us some time to prepare for the branching (e.g. set up rolling
upgrade bits and finish docs), we will go back to following the standard
OpenStack feature freeze starting at milestone 3 (2 weeks before branching).
Feature freeze exceptions may be granted for features that are important enough
and that are ready for landing by that date.
Please let me know if you have any questions.
Dmitry
__________________________________________________________________________
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
