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'.
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. :)
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'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?
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.
[1] https://review.openstack.org/#/c/205282/
[2] https://review.openstack.org/#/c/188244/
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
