Open Stack

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