Open Stack

On Sat, Dec 16, 2017 at 08:16:13AM -0600, Matt Riedemann wrote:
> On 12/16/2017 5:51 AM, Kashyap Chamarthy wrote:

Hi Matt,

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[2], 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
> pipeline.

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
realistic.

> 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
> ease. 

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
details.

> 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.

-- 
/kashyap