Open Stack

On 29 July 2015 at 19:13, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> We talked a bit about this at the nova mid-cycle last week but I can't say I
> completely remember all of the points made, since I feel like we talked
> ourselves into a circle that got us back to more or less 'the current specs
> and freeze process is the least of all evils so let's not change it'.

We did agree some small changes:
* open nova-specs for mitaka now
* refine the definition of the spec backlog

Continuing the changes since the summit:
* continue trying to focus review effort and get subteams recommending
priorities: http://etherpad.openstack.org/p/liberty-nova-priorities-tracking
* continue to actively mentor people around reviews, in the hope they
can join nova-core

The possible future changes we discussed were:
* look into how we adopt phabricator
* look at options adopting runways/kanban using phabricator

(I plan to do a thread on things from the midcycle next week, after
the immediate deadlines are all sorted)

But yes, in general, the reasons we have most of the processes in
place still hold, and it still seems the fairest way forward for both
our users and developers.

Its hard to imagine the progress we have made around Upgrades and v2.1
without this approach. Cells v2 and the Scheduler enhancements should
provide the ground work for a whole heap of crucial features our users
are requesting.

> Tomorrow is the feature freeze for nova but there is interest from a few
> people in getting rbd snapshot support into liberty.  The code is up for
> review [1] but the spec is not approved [2].
>
> With the process we have in place we can basically -2 this and say
> re-propose it for mitaka.
>
> One thing mentioned at the mid-cycle was what if people reviewed the spec
> and approved it, but marked the blueprint for 'next' so it's not actually
> tracked for liberty, but if the blueprint is approved and people are willing
> to review the code, it could land in liberty.
>
> The obvious downside here is the review burden, we have freeze deadlines in
> place to avoid a continual demand for feature review when we have bugs to
> fix before we release.  And it's not fair to the other people that already
> got their specs and blueprints approved with code up weeks or months ago but
> haven't had review attention and will just be deferred to another release.
> So we just end up with everyone being unhappy. :)

The idea of the freeze is to concentrate review effort on merging more
bug fixes and code related to priorities.

Honestly, delaying any of the blueprints really depresses me. People
have worked hard on following all our processes, and preparing the
code, almost always fixing real problems and enabling new use cases
for users that really need those features. But at some point, we have
to stop reviewing those, so we can work on our community agreed
priorities, and fix the issues in what we already have in tree.

> I'm trying to think of a way in which we could say, yeah, we've looked at
> the spec and this looks good, but don't expect it to land in the current
> release given other priorities and all of the other things we have actually
> agreed to review for this release (blueprint-wise). Basically your change
> goes on a backlog and come mitaka your blueprint could be moved from 'next'
> to the current release so it's part of the dashboard for tracking.

I was assuming we would do that by merging the nova-spec in Mitaka
directory, or for spec-less blueprints, we can just approve the
blueprint for Mitaka (via the nova-meeting in the usual way).

Or am I miss-reading your suggestion?

> I'm not sure how that would work with re-proposing the spec, I assume that
> would stay the same, but at least then you can just slap the
> 'previously-approved' tag in the spec commit and it's a fast path to
> re-approval.
>
> This would also avoid the -2 on the code change which might prevent people
> from reviewing it thinking it's a waste of time.
>
> The goal is to ease the frustration of people trying to get specs/blueprints
> approved after freeze but also balance that with an understanding that there
> are priorities and limits to the amount of time reviewers can spend on these
> things - so you know, don't come nagging in IRC every 5 minutes to review
> your thing which isn't planned for the current release. Is there a middle
> ground?

I hope so.

For context, we had around 100 pending spec reviews and at the same
time around 100 blueprints approved, at one point this cycle (I think
those number are about right). Hence the move to draw a line in the
sand, and get folks to shout up if they felt they were on the wrong
side of that. We had a week or so time window for that, which I
totally acknowledge is hard work and easy to miss, even more so for
folks not working on Nova full time. We did pre-announce the dates a
month or so in advance, the process to try and make that easier to
deal with, I am actively looking/thinking for better ways to do this.

> This is just spit-balling.  I really don't want this thread to turn into how
> the current process is ruining the world and killing babies, or how the
> review team isn't scaling and needs to be tripled or dissolved, etc etc,
> those ultimately don't seem to get anywhere constructive.

As discussed at the midcycle, my preference is to adopt a
Runway/Kanban style system, to replace all the non-priority freeze
dates (and priority etherpads, possibly). It seems like phabricator
could give us the tooling for that, but I am yet to experiment with it
properly.

That models the development as flow through the system, so we can look
at review queues for priority and non-priority items. That means we
can always add items to either queues, and just limit the relative
sizes of the queue to help keep the balance between priorities and
non-priority items. In theory all the chunks want to be the same size
in the queue, which will probably mean we start with a relatively high
number for the work in progress items, but it seems doable.

Getting that to feel lightweight, and get it integrated with our
existing tooling, will take some substantial work, but I like the
basic concepts there. It should be less lumpy and more flexible that
the current course grained freeze.

I find it hard to express my intent for these things via the ML, I
hope the above makes sense. I would love to get ttx invovled reviewing
these ideas, as he has superb intuition (for want of a better word)
around these kinds of things.

Thanks,
John