<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 8:45 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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>
</span>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></blockquote><div><br></div><div>I think it does have a benefit. Giving a spec implementation patches, commonly signals to reviewers to not review this patch (a -2 looks scary). Instead of there was a depends-on no scary -2 is needed, we also wouldn't need to hunt down the -2er and ask them to remove it (can be a delay due to timezones). Anything that reduces the number of procedural -2s we need is a good thing IMHO. But that doesn't mean we should require folks to do this, we can try it out on a few patches and see how it goes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<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>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>