Open Stack

On Tue, Aug 19, 2014 at 11:57 AM, James Slagle <james.slagle at gmail.com>
wrote:

> On Tue, Aug 19, 2014 at 1:58 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> >
> > While I cannot speak for the dynamics of the tripleo team, if this were
> to
> > be adopted in nova I would not +2 any blueprints as I don't think I can
> > commit to *guaranteeing* I will have even more review bandwidth, I can
> make
> > best efforts but a personally cannot guarantee.
>
> I'm pretty sure we're all humans here, although there may be some bots
> among us :). We're all working on "best effort", there are no 100%
> guarantees.
>
> It's a commitment...no point arguing semantics of guarantee vs
> commitment. But, it's not about seeking to punish people that are
> acting in good faith, who may be unable to deliver on that commitment
> for whatever reason.
>
> This is just an attempt to codify and record who is signing up to do
> the review workload on a given spec. Why +2 a spec yet not commit to
> doing a best effort at reviewing the patches? Is there just hope that
> the review burden is going to get "absorbed" by others in the
> community?
>
>
Nova tried this a cycle or two back, we did something like all blueprints
with a priority greater then low needed two core review sponsors.
Unfortunately the experiment didn't work. So we have reverted back to the
model where the review burden gets 'absorbed' by the community. I think
this works better for nova due to not not knowing when when code will be
ready for review and not knowing when reviewers are available.



> I think that's the approach that is clearly not working, hence the
> different ideas floating around the list about how to limit the scope
> of the changes currently in flight. You could say, well, we'll only
> have X slots for approved specs at any one time, but that doesn't
> address the question of who, if anyone, is going to be giving their
> best effort to review those changes. I suppose if things are limited
> sufficiently, everyone will have enough time to review everything. The
> approach we're suggesting here just looks at the problem differently,
> it gives folks the opportunity to say, I'm going to focus on reviewing
> these changes without dropping all my other reviews. And of course
> this is just one of the criteria laid out on the wiki page before
> approving a spec, amongst many
>

In nova, we have a large number of contributors with a fairly small core
review team (for how large a repo we have) and a large number of blueprints
while tripleo has the same size review team, fewer contributors and fewer
blueprints. So I don't think there is a one size fits all solution here
(you have significantly fewer blueprints then us), and hopefully this works
for tripleo.


> --
> -- James Slagle
> --
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/679a3104/attachment.html>