On 7/29/15, 2:13 PM, "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'. > >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-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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