On 25 February 2015 at 00:05, Thierry Carrez <thie...@openstack.org> wrote: > Daniel P. Berrange wrote: >> [...]
> > I think you're judging the cycle from the perspective of developers > only. You said that in the other thread, and I think its false. There is a very good case to be made that the release cycle is directly responsible for: - increased feature latency [when users get new shiny] - already explained here. - decreased stability due to feature crush - decreased quality for the same reason - we don't put things in and bake them before exposing, we get them in and since there is a long gap before they can be consumed they're generally just enabled immediately. Keystone's steps to address that are excellent, but made harder by the gap between releases: there is social pressure to make things graduate to support within each release. > 6 months was not an arbitrary decision. Translations and > documentation teams basically need a month of feature/string freeze in > order to complete their work. Since we can't reasonably freeze one month > every 2 months, we picked 6 months. Do they need a month because 6 months worth of changes have been aggregated? E.g. if they have 2 months of changes to deal with, do they need 1.5 weeks? Perhaps we could branch the code release in advance of docs and translations, and announce the release when those artifacts are ready? > It's also worth noting that we were on a 3-month cycle at the start of > OpenStack. That was dropped after a cataclysmic release that managed the > feat of (a) not having anything significant done, and (b) have out of > date documentation and translations. Oh! https://wiki.openstack.org/w/index.php?title=Obsolete:3MonthReleaseCycle&direction=prev&oldid=14016 appears to be the page about that, but my google-fu isn't turning up a post-mortem of the C release which prompted the change. Perhaps some old-hand like you can fill us in on the details :). > Stable branches may have the luxury of skipping releases and designate a > "stable" one from time to time (I reject the Linux comparison because > the kernel is at a very different moment in software lifecycle). The > trick being, making one release "special" is sure to recreate the peak > issues you're trying to solve. > > I'm actually more concerned about the teams that don't have the luxury > of skipping a release (like the vulnerability management team). Docs and > translations, as mentioned above, will also have a hard time producing > quality docs and translations every 2 months with a very short freeze > period. I agree that the vulnerability team will be rather more impacted by this than regular project teams - I made a nod to that in the other thread. More thought needed still :). > I may appear defensive on my answers, but it's not my goal to defend the > current system: it's just that most of those proposals generally ignore > the diversity of the needs of the teams that make OpenStack possible, to > focus on a particular set of contributors' woes. I'm trying to bring > that wider perspective in -- the current system is a trade-off and the > result of years of evolution, not an arbitrary historic choice that we > can just change at will. I agree that its not arbitrary and that changing it requires some appropriate wide-spread consultation; OTOH the benefits of rolling and higher frequency releases are really substantial: but we have to backup the change with the appropriate engineering (such as reducing our frictions that cause teams practicing CD to be weeks behind tip) to make it feasible. My greatest concern about the proposals happening now is that we may bite off more than we can chew. OTGH the reality is that all the negative things multiply out, so we probably need to just start somewhere and /do/ to give us the space to fix other things. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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
