Open Stack

On 5/27/2015 7:21 PM, John Griffith wrote:
>
>
> On Wed, May 27, 2015 at 12:15 PM, Joe Gordon <joe.gordon0 at gmail.com
> <mailto:joe.gordon0 at gmail.com>> wrote:
>
>
>
>     On Tue, May 26, 2015 at 8:45 AM, Daniel P. Berrange
>     <berrange at redhat.com <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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
>
>
>
> __________________________________________________________________________
> 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
>

I agree with jgriffith here, I don't really want to see yet another 
layer added to the onion that is the blueprint process.

We have procedural -2 for a reason.  We have had features merged in code 
before the spec and blueprint is approved, so this happens and that's 
why I procedural -2 things when I see them (the Depends-On would be an 
insurance policy against merging code changes before the spec is 
approved, so if people want to use it, go nuts, but I don't think it 
should be a required part of the process).  As a core you could also 
find the spec change and add the Depends-On yourself since Gerrit makes 
that easy, if you're so inclined.

When I give a procedural -2 I leave a comment explaining why and that 
I'll remove it when the blueprint is approved, with a link to the 
blueprint process wiki.

I hope people's feelings aren't getting hurt with a procedural -2, but 
seriously, it's a big project and there isn't time for hand-holding 
everything and everyone, so if people have questions about the process 
they need to use our communication mediums like IRC for getting answers.

-- 

Thanks,

Matt Riedemann