<div dir="ltr">I think this will help because it separates the judgement of "is this code good enough to land" from the project and release coordination of "should this code land now". <br><div><br></div><div>I've been floating the idea of separating +2 and +A powers for the same purpose: free up many of the technical reviewers from having to *also* think about release schedules and project priorities, since larger projects are tending towards having a smaller group of "project-drivers" who handle the latter question.</div><div><br></div><div>It looks like Depends-On is one way to address that, and it's fairly light weight; since we can edit the review message, core-reviewers can add that line if they feel it's needed, without needing to -1 the code in question. I'm open to trying it in the Ironic project.</div><div><br></div><div>-Devananda</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 26, 2015 at 8:45 AM Daniel P. Berrange <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, May 22, 2015 at 02:57:23PM -0700, Michael Still wrote:<br>
> Hey,<br>
><br>
> it would be cool if devs posting changes for nova which depend on us<br>
> approving their spec could use Depends-On to make sure their code<br>
> doesn't land until the spec does.<br>
<br>
Does it actually bring any benefit ?  Any change for which there is<br>
a spec is already supposed to be tagged with 'Blueprint: foo-bar-wiz'<br>
and nova core devs are supposed to check the blueprint is approved<br>
before +A'ing it.  So also adding a Depends-on just feels redundant<br>
to me, and so is one more hurdle for contributors to remember to<br>
add. If we're concerned people forget the Blueprint tag, or forget<br>
to check blueprint approval, then we'll just have same problem with<br>
depends-on - people will forget to add it, and cores will forget<br>
to check the dependant change. So this just feels like extra rules<br>
for no gain and extra pain.<br>
<br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>