> On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
> > On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery <mest...@mestery.com>
> wrote:
> > > > I really like this idea, as Michael and others alluded to in
> > > > above, we
> > > are
> > > > attempting to set cycle goals for Kilo in Nova. but I think it is
> > > > worth doing for all of OpenStack. We would like to make a list of
> > > > key goals
> > > before
> > > > the summit so that we can plan our summit sessions around the
> > > > goals. On a really high level one way to look at this is, in Kilo
> > > > we need to pay down our technical debt.
> > > >
> > > > The slots/runway idea is somewhat separate from defining key cycle
> > > goals; we
> > > > can be approve blueprints based on key cycle goals without doing slots.
> > >  But
> > > > with so many concurrent blueprints up for review at any given
> > > > time, the review teams are doing a lot of multitasking and humans
> > > > are not very
> > > good at
> > > > multitasking. Hopefully slots can help address this issue, and
> > > > hopefully allow us to actually merge more blueprints in a given cycle.
> > > >
> > > I'm not 100% sold on what the slots idea buys us. What I've seen
> > > this cycle in Neutron is that we have a LOT of BPs proposed. We
> > > approve them after review. And then we hit one of two issues: Slow
> > > review cycles, and slow code turnaround issues. I don't think slots
> > > would help this, and in fact may cause more issues. If we approve a
> > > BP and give it a slot for which the eventual result is slow review
> > > and/or code review turnaround, we're right back where we started.
> > > Even worse, we may have not picked a BP for which the code submitter
> > > would have turned around reviews faster. So we've now doubly hurt
> > > ourselves. I have no idea how to solve this issue, but by over
> > > subscribing the slots (e.g. over approving), we allow for the
> > > submissions with faster turnaround a chance to merge quicker. With
> > > slots, we've removed this capability by limiting what is even
> > > allowed to be considered for review.
> > >
> >
> > Slow review: by limiting the number of blueprints up we hope to focus
> > our efforts on fewer concurrent things slow code turn around: when a
> > blueprint is given a slot (runway) we will first make sure the
> > author/owner is available for fast code turnaround.
> >
> > If a blueprint review stalls out (slow code turnaround, stalemate in
> > review discussions etc.) we will take the slot and give it to another
> blueprint.
>  On Wed , Aug 13, 2014 Daniel Berrange wrote:
> This idea of fixed slots is not really very appealing to me. It sounds like 
> we're
> adding a significant amount of buerocratic overhead to our development
> process that is going to make us increasingly inefficient.
> I don't want to waste time wating for a stalled blueprint to time out before
> we give the slot to another blueprint. On any given day when I have spare
> review time available I'll just review anything that is up and waiting for
> review. If we can set a priority for the things up for review that is great 
> since I
> can look at those first, but the idea of having fixed slots for things we 
> should
> review does not do anything to help my review efficiency IMHO.
> I also thing it will kill our flexibility in approving & dealing with changes 
> that
> are not strategically important, but none the less go through our
> blueprint/specs process. There have been a bunch of things I've dealt with
> that are not strategic, but have low overhead to code and review and easily
> dealt with in the slack time between looking at the high priority reviews. It
> sounds like we're going to loose our flexibility to pull in stuff like this 
> if it only
> gets a chance when strategically imporatant stuff is not occupying a slot
> Regards,
> Daniel
> --

I am also not in favour of this fixed slots approach because of the potential 
lack of flexibility and overhead that could be introduced in the process. 

There has been lots of great mailing list traffic over the last month about 
blueprint spec freeze deadlines, exceptions, review priorities, inter-project 
dependencies on approvals, etc. We had a brief discussion in the NFV working 
group [1] and this is a really creative thread on how we can address some of 
the challenges in getting a proposal from concept through to blueprint 
acceptance and code integration.  I think some of the difficulty on converging 
on a proposal in this thread stems from the number of problem statements that 
are being addressed simultaneously. 

In no particular order and not an exhaustive list, here are some of the 
challenges that I've seen mentioned on this thread and others so far:
- There is an imbalance between strategic and tactical submissions.
- There is growing technical debt and lack of clarity on how that should be 
dealt with.
- There is inconsistency, and in some cases a lack of clarity, in how the 
entire lifecycle of a new proposal is dealt with within projects and across 
projects. E.g. What the various checkpoints on the lifecycle of a new proposal 
mean. What does having a blueprint accepted really imply and even more 
importantly what does it not imply?
- There is a difficulty in predicting the time required for the various stages 
in the lifecycle of new proposals. E.g. No SLA on when blueprint or code 
reviews may happen, and negative feedback (which could be completely valid) can 
come in just before a deadline giving the submitter little chance to address 
comments in time for the deadline.
- There is a lack of clarity and consistency in how proposals that are 
progressing slowly should be dealt with from both submitter and 
reviewer/approver perspectives.
- There is a lack of clarity on how best to progress cross-project proposals 
that have interdependencies that need to land in the same release.
- There is a lack of clarity and consistency on how to appeal decisions.

There are several great wikis that aim to provide guidance on how to navigate 
the blueprint process and general guides on community participation [2], [3], 
[4], [5], etc. Ultimately I think these need to be harmonized to reflect any 
new process that may be defined. 

One proposal in this thread that I would really welcome was from Rochelle 
Grober who wrote:
"Each BP and each spec should have at least one core that "owns" it.  They will 
watch it more closely and at least be willing to answer questions, discuss 
designs, or find another developer who will shepherd the assigned developer 
through the process (if they need it)". 
Assuming a core is assigned/volunteers, then having them mentor new proposals 
would be a very effective way to help contributors navigate OpenStack. I would 
also propose to extend this with a type of honour system so that when a 
contributor gets this type of help on a proposal, they subsequently volunteer 
to mentor two more proposals, at a minimum from a process perspective. This 
should help reduce the load on the cores and contribute something back to the 


[2] https://wiki.openstack.org/wiki/Blueprints 
[3] https://wiki.openstack.org/wiki/NeutronReviews 
[4] http://bit.ly/navigating-openstack-community 
[5] https://wiki.openstack.org/wiki/Juno_Release_Schedule

Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

OpenStack-dev mailing list

Reply via email to