<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 9:41 AM, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
tl;dr;<br>
<br>
At the summit, the Ironic team discussed the challenges we've had with<br>
the current release model and came up with some ideas to address them.<br>
I had a brief follow-up conversation with Doug and Thierry, but I'd<br>
like this to be discussed more openly and for us (the Ironic dev<br>
community) to agree on a clear plan before we take action.<br>
<br>
If Ironic moves to a release:independent model, it shouldn't have any<br>
direct effect on other projects we integrate with -- we will continue<br>
to follow release:at-6mo-cycle-end -- but our processes for how we get<br>
there would be different, and that will have an effect on the larger<br>
community.<br>
<br>
Longer version...<br>
<br>
We captured some notes from our discussion on Thursday afternoon's etherpad:<br>
<a href="https://etherpad.openstack.org/p/liberty-ironic-scaling-the-dev-team" target="_blank">https://etherpad.openstack.org/p/liberty-ironic-scaling-the-dev-team</a><br>
<br>
Which I've summarized below, and mixed in several themes which didn't<br>
get captured on the 'pad but were discussed somewhere, possibly in a<br>
hallway or on Friday.<br>
<br>
Current challenges / observations:<br>
- six weeks' feature freeze is not actually having the desired<br>
stabilizing effect<br>
- the post-release/pre-summit slump only makes that worse<br>
- many folks stop reviewing during this time because they know their<br>
own features won't land, and instead focus their time downstream<br>
- this creates pressure to land features which aren't ready, and<br>
leaves few people to find bugs, write docs, and generally prepare the<br>
release during this window<br>
<br>
The alternative we discussed:<br>
- use feature branches for risky / large work, keeping total # of<br>
branches small, and rebasing them regularly on master<br>
- keep trunk moving quickly for smaller / less risky / refactoring changes<br>
- "slow down" for a week or two before a release, but dont actually<br>
freeze master<br>
- cut releases when new features are available<br>
- OpenStack coordinated releases are taken from latest independent release<br>
- that release will then get backports & stable maintenance, other<br>
independent releases don't<br>
<br>
We think this will accomplish a few things:<br>
- make the developer experience better by being more consistent, thus<br>
keeping developers engaged year-round and increase the likelyhood<br>
they'll find and fix bugs<br>
- reduce stress on core reviewers since there's no "crunch time" at<br>
the end of a cycle<br>
- allow big changes to "bake" in a feature branch, rather than in a<br>
series of gerrit patches that need to be continually re-reviewed and<br>
cherry-picked to test them.<br>
- allow operators who wish to use Ironic outside of OpenStack to<br>
consume feature releases more rapidly, while still consuming approved<br>
releases instead of being forced to deploy from trunk<br>
<br>
<br>
For reference, Michael has posted a tracking change to the governance<br>
repo here: <a href="https://review.openstack.org/#/c/185203/" target="_blank">https://review.openstack.org/#/c/185203/</a><br>
<br>
Before Ironic actually makes the switch, I would like us to discuss<br>
and document the approach we're going to take more fully, and get<br>
input from other teams on this approach. Often, the devil is in the<br>
details - and, for instance, I don't yet understand how we'll fit this<br>
approach into SemVer, or how this will affect our use of launchpad to<br>
track features (maybe it means we stop doing that?).<br></blockquote><div><br></div><div>Sounds like a great plan.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Input appreciated.<br>
<br>
Thanks,<br>
Devananda<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>