<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 3, 2015 at 9:45 AM, James Bottomley <span dir="ltr"><<a href="mailto:James.Bottomley@hansenpartnership.com" target="_blank">James.Bottomley@hansenpartnership.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Tue, 2015-02-24 at 12:05 +0100, Thierry Carrez wrote:<br>
> Daniel P. Berrange wrote:<br>
> > [...]<br>
> > The key observations<br>
> > ====================<br>
> ><br>
> > The first key observation from the schedule is that although we have<br>
> > a 6 month release cycle, we in fact make 4 releases in that six<br>
> > months because there are 3 milestones releases approx 6-7 weeks apart<br>
> > from each other, in addition to the final release. So one of the key<br>
> > burdens of a more frequent release cycle is already being felt, to<br>
> > some degree.<br>
> ><br>
> > The second observation is that thanks to the need to support a<br>
> > continuous deployment models, the GIT master branches are generally<br>
> > considered to be production ready at all times. The tree does not<br>
> > typically go through periods of major instability that can be seen<br>
> > in other projects, particular those which lack such comprehensive<br>
> > testing infrastructure.<br>
> ><br>
> > The third observation is that due to the relatively long cycle, and<br>
> > increasing amounts of process, the work accomplished during the<br>
> > cycles is becoming increasingly bursty. This is in turn causing<br>
> > unacceptably long delays for contributors when their work is unlucky<br>
> > enough to not get accepted during certain critical short windows of<br>
> > opportunity in the cycle.<br>
> ><br>
> > The first two observations strongly suggest that the choice of 6<br>
> > months as a cycle length is a fairly arbitrary decision that can be<br>
> > changed without unreasonable pain. The third observation suggests a<br>
> > much shorter cycle length would smooth out the bumps and lead to a<br>
> > more efficient & satisfying development process for all involved.<br>
><br>
> I think you're judging the cycle from the perspective of developers<br>
> only. 6 months was not an arbitrary decision. Translations and<br>
> documentation teams basically need a month of feature/string freeze in<br>
> order to complete their work. Since we can't reasonably freeze one month<br>
> every 2 months, we picked 6 months.<br>
<br>
</div></div>Actually, this is possible: look at Linux, it freezes for 10 weeks of a<br>
12 month release cycle (or 6 weeks of an 8 week one).  More on this<br>
below.<br>
<div><div class="h5"><br>
> It's also worth noting that we were on a 3-month cycle at the start of<br>
> OpenStack. That was dropped after a cataclysmic release that managed the<br>
> feat of (a) not having anything significant done, and (b) have out of<br>
> date documentation and translations.<br>
><br>
> While I agree that the packagers and stable teams can opt to skip a<br>
> release, the docs, translations or security teams don't really have that<br>
> luxury... Please go beyond the developers needs and consider the needs<br>
> of the other teams.<br>
><br>
> Random other comments below:<br>
><br>
> > [...]<br>
> > Release schedule<br>
> > ----------------<br>
> ><br>
> > First the releases would probably be best attached to a set of<br>
> > pre-determined fixed dates that don't ever vary from year to year.<br>
> > eg releses happen Feb 1st, Apr 1st, Jun 1st, Aug 1st, Oct 1st, and<br>
> > Dec 1st. If a particular release slips, don't alter following release<br>
> > dates, just shorten the length of the dev cycle, so it becomes fully<br>
> > self-correcting. The even numbered months are suggested to avoid a<br>
> > release landing in xmas/new year :-)<br>
><br>
> The Feb 1 release would probably be pretty empty :)<br>
><br>
> > [...]<br>
> > Stable branches<br>
> > ---------------<br>
> ><br>
> > The consequences of a 2 month release cycle appear fairly severe for<br>
> > the stable branch maint teams at first sight. This is not, however,<br>
> > an insurmountable problem. The linux kernel shows an easy way forward<br>
> > with their approach of only maintaining stable branches for a subset<br>
> > of major releases, based around user / vendor demand. So it is still<br>
> > entirely conceivable that the stable team only provide stable branch<br>
> > releases for 2 out of the 6 yearly releases. ie no additional burden<br>
> > over what they face today. Of course they might decide they want to<br>
> > do more stable branches, but maintain each for a shorter time. So I<br>
> > could equally see them choosing todo 3 or 4 stable branches a year.<br>
> > Whatever is most effective for those involved and those consuming<br>
> > them is fine.<br>
><br>
> Stable branches may have the luxury of skipping releases and designate a<br>
> "stable" one from time to time (I reject the Linux comparison because<br>
> the kernel is at a very different moment in software lifecycle). The<br>
> trick being, making one release "special" is sure to recreate the peak<br>
> issues you're trying to solve.<br>
<br>
</div></div>I don't disagree with the observation about different points in the<br>
lifecycle, but perhaps it might be instructive to ask if the linux<br>
kernel ever had a period in its development history that looks somewhat<br>
like OpenStack does now.  I would claim it did: before 2.6, we had the<br>
odd/even develop/stabilise cycle.  The theory driving it was that we<br>
needed a time for everyone to develop then a time for everyone to help<br>
make stable.  You yourself said this in the other thread:<br>
<br>
> Joe Gordon wrote:<br>
> > [...]<br>
> > I think a lot of the frustration with our current cadence comes out of<br>
> > the big stop everything (development, planning etc.), and stabilize the<br>
> > release process. Which in turn isn't really making things more stable.<br>
><br>
> I guess I have a different position. I think the release candidate<br>
> period is the only thing that makes your code drops actually usable.<br>
> It's the only moment in the cycle where integrators test. It's the<br>
> only<br>
> moment in the cycle where developers work on bugs they did not file<br>
> themselves, but focus on a project-wide priority list of release<br>
> blockers. If you remove that period, then nobody will ever work on<br>
> release blockers that do not directly affect them. Shorten that period<br>
> to one week, and no integrator will have the time to run a proper QA<br>
> program to detect those release blockers.<br>
<br>
This is a precise echo of the driver for the Linux kernel odd/even<br>
develop/stabilise cycle.  However, the develop/stabilise cycle lead to a<br>
huge amount of frustration from people who wanted to add new features<br>
while we were stabilising (and from distributions who needed a release<br>
while we were developing).<br>
<br>
In the beginning, for Linux Kernel: 0.9/1.0; 1.1/1.2; 1.3/2.0; 2.1/2.2<br>
all had relatively short cycles for develop/stabilise, but the<br>
frustrations in the system meant that by the time we got to 2.3/2.4 the<br>
cycle was out of control and 2.5 exploded for us and led to the adoption<br>
of the new model for 2.6 that you see today.<br>
<br>
The ultimate way we resolved the tensions was to acknowledge that<br>
developers will develop.  If they're interested, they'll help you<br>
stabilise, but if not they'll just back bite about their frustrations<br>
trying to get their next feature in.  Conversely, you have a whole<br>
ecosystem (the OpenStack distributions) interested in stability, so<br>
they'll help you stabilise. So the Linux Kernel now do an overlapping<br>
develop/release cycle, where it looks like we stabilise for n-2 weeks of<br>
the n week cycle, but in reality developers develop the N+1 release in<br>
that time-frame and the people interested in stability stabilise the<br>
release.  The result is that a lot of the developer frustration<br>
evaporated (they only get yelled at if they try to discuss patches with<br>
maintainers in the 2-week merge window period) and stability hasn't<br>
really suffered.<br>
<br>
This is a long winded way of saying that Daniel has the right idea (in<br>
my opinion) but it would depend on adopting different processes than<br>
today.<br></blockquote><div><br></div><div>For fun, here is a really old thread, that tried to suggest a kernel-like process:<br>"Nova subsystem branches and feature branches"<br><a href="http://www.gossamer-threads.com/lists/openstack/dev/12708">http://www.gossamer-threads.com/lists/openstack/dev/12708</a><br><br></div><div>-Angus<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888"><br>
James<br>
</font></span><div class=""><div class="h5"><br>
<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>
</div></div></blockquote></div><br></div></div>