Open Stack

On 22 January 2016 at 02:38, Robert Collins <robertc at robertcollins.net> wrote:
> On 21 January 2016 at 07:38, Ian Cordasco <ian.cordasco at 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