On 5/27/2015 7:21 PM, John Griffith wrote:
On Wed, May 27, 2015 at 12:15 PM, Joe Gordon <[email protected] <mailto:[email protected]>> wrote: On Tue, May 26, 2015 at 8:45 AM, Daniel P. Berrange <[email protected] <mailto:[email protected]>> 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: [email protected]?subject:unsubscribe <http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe <http://[email protected]?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: [email protected]?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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
