On 29 July 2015 at 19:13, Matt Riedemann <mrie...@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 __________________________________________________________________________ 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