On 22 January 2016 at 02:38, Robert Collins <robe...@robertcollins.net> wrote: > 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.
+1 on the need to fix the "big issues" facing projects. By "big issues" I mean problems that affect almost all users. Stability and Technical Debt are just two "big issues". For me, doing bug triage, code reviews, fixing the gate are all in that list. In Nova we are trying to dedicate time in every cycle to the big issues facing the project. We do that using by picking priorities, and the non-priority feature freeze. There is a very rough write up on that process from liberty here: http://docs.openstack.org/developer/nova/process.html#non-priority-feature-freeze It has allowed us to get rolling upgrades working and evolve our API to do micro-versioning. It has also lead to a big backlog of other code people want to push, lots of it already in production. There are other issues here, and lots of ideas on the table, but lets not go down that rabbit hole on email. +1 for having a TC statement to set exceptions. That should help developers unable to get permission. Hopefully developers will also get asked to work on these things. +1 documenting common patterns for projects to adopt. -1 for making projects to adopt a "stability" cycle. Feels better as a suggested pattern. (Although it feels a little like an anti-pattern) Thanks, johnthetubaguy __________________________________________________________________________ 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
