[openstack-dev] [Nova] Using depends-on for patches which require an approved spec

John Griffith john.griffith8 at gmail.com
Thu May 28 00:21:04 UTC 2015


On Wed, May 27, 2015 at 12:15 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

>
>
> On Tue, May 26, 2015 at 8:45 AM, Daniel P. Berrange <berrange at redhat.com>
> wrote:
>
>> On Fri, May 22, 2015 at 02:57:23PM -0700, Michael Still wrote:
>> > Hey,
>> >
>> > it would be cool if devs posting changes for nova which depend on us
>> > approving their spec could use Depends-On to make sure their code
>> > doesn't land until the spec does.
>>
>> Does it actually bring any benefit ?  Any change for which there is
>> a spec is already supposed to be tagged with 'Blueprint: foo-bar-wiz'
>> and nova core devs are supposed to check the blueprint is approved
>> before +A'ing it.  So also adding a Depends-on just feels redundant
>> to me, and so is one more hurdle for contributors to remember to
>> add. If we're concerned people forget the Blueprint tag, or forget
>> to check blueprint approval, then we'll just have same problem with
>> depends-on - people will forget to add it, and cores will forget
>> to check the dependant change. So this just feels like extra rules
>> for no gain and extra pain.
>>
>
> 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.
>
>
>>
>> Regards,
>> Daniel
>> --
>> |: http://berrange.com      -o-
>> http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-
>> http://virt-manager.org :|
>> |: http://autobuild.org       -o-
>> http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-
>> http://live.gnome.org/gtk-vnc :|
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ​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:
1. spec
2. blueprint
3. patch with link to blueprint
and now
4. patch with tag Depends-On: spec

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.​

Certainly not saying I oppose the idea, just wondering about how much
red-tape we create and what we do with it all.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150527/809530b7/attachment.html>


More information about the OpenStack-dev mailing list