[openstack-dev] [all] Switching to longer development cycles
kchamart at redhat.com
Sun Dec 17 20:09:28 UTC 2017
On Sat, Dec 16, 2017 at 08:16:13AM -0600, Matt Riedemann wrote:
> On 12/16/2017 5:51 AM, Kashyap Chamarthy wrote:
First, thanks for the detailed reply with specific examples.
> > But one pontential question that comes to mind from that old thread is
> > how is this new proposal of 'one coordinated release per year' going to
> > address the following:
> > If your spec didn't make into this year's coordiated release, then
> > does it have to 'sit out' for one whole year?
> > The shorter release cycle argument addresses that by not coupling specs
> > to a single release -- where specs can be submitted regardless of a
> > release in question. Meanwhile, code development of the feature can
> > happen over several cycles. And periodically re-evaluate it in light of
> > new evidence and design discussions.
> > As it stands, this problem seems mitgated by moving specs across
> > releases and re-approving them (insofar as they make sense). Maybe in
> > current times, the above specs issue is 'non-problem'. Happy to be
> > corrected.
> Each project would have to decide what works for them, which might mean one
> or two intermediate releases within the 1 year coordinated release where we
> have a freeze period for new features, and then open up again for new spec
> reviews after the intermediate release to allow new content in again. If no
> one is picking up the intermediate release, then it's just self-imposed to
> force us to (1) work toward a deadline and not let things drag on for a year
> and (2) allow in new specs more than once a year so the above problem
> doesn't happen, or is at least mitigated.
Okay, the above approach of per-project based decision to do
intermediate releases sounds reasonable.
> There are also comments elsewhere in this thread about extending the
> stability period, but again, that's per-project at this point. The proposal
> says nothing about a coordinated stability period.
Noted. (Haven't caught up with all the responses yet.)
> In the last few cycles we've had I think 2 weeks between the global feature
> freeze and RC1, which isn't much time for stability and flushing out last
> minute bugs.
> If we tried to incorporate both multiple freezes and stability periods, we
> might have something like:
> * 3 months of new dev (maybe freeze specs after a month?)
> * 1 month of no new feature work, only bugs, docs, testing
> * intermediate release
> * <repeat until the coordinated yearly release>
> That would give you a shorter dev cycle than what we do today (at least in
> nova), and do it three times in a year.
> The only contributor problem this solves is people have more opportunities
> to get their spec/new feature considered, at least more than once in a year.
> It does not, however, automatically make those specs/new features a priority
> to get review and help from the core team to shepherd them through the
Yes, that's a good point. 'Consideration' is one thing, getting the
spec / feature to its logical conclusion is something else.
> There was some discussion about the priority issue during the TC office
> hours a few days ago, and Dan Smith has said it elsewhere in this thread.
> The chances of getting work done is proportional to the shared understanding
> and value of the thing being proposed, including risk/size/complexity etc.
Agreed, there are several complex variables here, and not everything can
be so cut-and-dried.
> Here are two concrete examples from part time contributors for nova:
> 1. https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/rebuild-keypair-reset.html
> 2. https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/scaleio-ephemeral-storage-backend.html
[...] # Snip description of the above two examples.
> How do we solve that problem? Get someone from Dell/EMC to be full time
> active in Nova for a year or more and build the trust of the core team to
> want to review this change, and trust that the contributors will be around
> to maintain it after it's merged? That's not a realistic solution.
/me nods; I see your point. And I agree, the above hypothetical is not
> We could dig up the slots/runways idea where we essentially do Kanban and
> this gets queued up and the core team must get it in eventually to start new
> work, regardless of priority.
While I remember the terms "slots/runways" but forgot what the idea
entails (I'll look it up).
> I don't have an answer. There are options. The 1 year release idea doesn't
> magically solve this problem. And arguably doing 3 intermediate releases per
> year, if we did that to solve the "missed the 1 year boat" issue, would add
> stress to the core team/PTL because they are doing more context switching
> and schedule management, precisely what the 1 year release is proposing to
I agree that anything that adds more paperwork or aggravates context
switching is a net-negative. Probably we should aim at reducing the
stress factors involved in doing one or two intermediate releases for
Nova (as a per-project decision). They don't need to go through a huge
procedural dance. Blessed / offical tarballs with automated testing,
released on a fixed time-based schedule should be fine, IMHO. Or else
it (the stress) might accumulate to the end of the year-long cycle.
/me knows he's hand-waving here a bit, and the devil _is_ in the
> Granted, if the intermediate release has much less content then maybe
> it'd be fine.
Yes, the stress factor would be a 'gradient' depending on how many
features are being proposed.
> Hard to say unless we just tried it.
Thanks for your response, it adds more nuance.
More information about the OpenStack-dev