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