On 21 January 2016 at 07:38, Ian Cordasco <ian.corda...@rackspace.com> wrote: > > I think this is a solid proposal but I'm not sure what (if anything) the TC > needs to do about this. This is something most non-corporate open source > projects do (and even some corporate open source projects). It's the natural > life-cycle of any software project (that we ship a bunch of things and then > focus on stability). Granted, I haven't seen much of a focus on it in > OpenStack but that's a different story. > > That said, I'd like to see a different release cadence for cycles that are > "stabilization cycles". We, as a community, are not using minor version > numbers. During a stabilization cycle, I would like to see master be released > around the 3 milestones as X.1.0, X.2.0, X.3.0. If we work that way, then > we'll be able to avoid having to backport a lot of work to the X.0 series and > while we could support X.0 series with specific backports, it would avoid > stressing our already small stable teams. My release strategy, however, may > cause more stress for downstream packages though. It'll cause them to have to > decide what and when to package and to be far more aware of each project's > current development cycle. I'm not sure that's positive.
So the reason this was on my todo this cycle - and I'm so glad Flavio has picked it up (point 9 of https://rbtcollins.wordpress.com/2015/11/02/openstack-mitaka-debrief/) - was that during the Tokyo summit, in multiple sessions, folk were saying that they wanted space from features, to consolidate already added things, and to cleanup accrued debt, and that without TC support, they couldn't sell it back to their companies. Essentially, if the TC provides some leadership here: maybe as little as: - its ok to do it [we think it will benefit our users] - sets some basic expectations And then individual projects decide to do it (whether thats a PTL call, a vote, core consensus, whatever) - then developers have a platform to say to their organisation that the focus is X, don't expect features to land - and that they are *expected* to help with the cycle. Without some framework, we're leaving those developers out in the cold trying to explain what-and-why-and-how all by themselves. -Rob -- Robert Collins <rbtcoll...@hpe.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
