<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 12:15 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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>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></span><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><span class=""><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><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><div><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></span></div><br></div></div>
<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>
<br></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">Seems ok, but I'm wondering if maybe others are doing specs differently. What I mean is, we seem to be growing a long process tail:</div><div class="gmail_default" style="font-family:monospace,monospace">1. spec</div><div class="gmail_default" style="font-family:monospace,monospace">2. blueprint</div><div class="gmail_default" style="font-family:monospace,monospace">3. patch with link to blueprint</div><div class="gmail_default" style="font-family:monospace,monospace">and now</div><div class="gmail_default" style="font-family:monospace,monospace">4. patch with tag Depends-On: spec</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I think we used to say "if there's a bp link and it's not approved don't merge" which seems similar. We've had so many "procedural" steps added/removed that who knows if I'm just completely out of sync or not.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Certainly not saying I oppose the idea, just wondering about how much red-tape we create and what we do with it all.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">John</div><br></div></div>