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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
