Open Stack

On 7/29/15, 2:13 PM, "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'.
>
>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

Feel free to throw things at me, but is the primary responsibility of a
core reviewer to review things or fix things? Horizontal scaling requires
more reviewing. I like to imagine a world where core reviewers mentor and
review and the rest community writes most of the code. I assumed that was
part of the implicit contract of becoming a core reviewer. One alternative
solution is to make core reviewers for specs a different set (intersection
is acceptable) of people that spend even less time writing code.


> 
>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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev