Open Stack

On 12/16/2017 5:51 AM, Kashyap Chamarthy wrote:
> Thinking a bit more, the above reminds of this[*] by DanPB a couple of
> years ago, where Dan's 'Modest Proposal' was: "switch to a development
> cycle that is exactly 2 months".
> 
> 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.

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.

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.

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.

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

#1 is already merged for queens (has been for awhile now). It's a global 
feature (not vendor backend specific) and not very complicated. The only 
downside is it's an API change so we're stuck supporting it forever if 
it turns out to be a bad idea.

#2 has been getting re-proposed for several cycles now (even before it 
was eventually approved in Pike). It's a large single-vendor change 
which piles onto existing technical debt. There is really only 
motivation from anyone at Dell/EMC to get this done and therefore it 
doesn't get much review so it continues to trudge forward. This isn't 
because we don't like those people (Feodor has done a lot of great work 
in nova over the years, and Eric has been very patiently rebasing this 
change and requesting review without being pushy). It's because we only 
have so many people doing reviews and we have higher priorities to spend 
our review time on - or we have other low priority blueprints which 
simply have higher shared value.

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.

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.

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. Granted, if the intermediate release has 
much less content then maybe it'd be fine. Hard to say unless we just 
tried it.

-- 

Thanks,

Matt