Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
Sean Dague wrote: I want StoryBoard more than anyone else. However future Puppies and Unicorns don't fix real problems right now. With the tools already at our disposal, just using them a different way, I think we can fix some real problems. I think, more importantly, we're going to discover a whole new class of problems because we're not blocked on launchpad. FWIW this model is not incompatible with StoryBoard at all. A feature story in StoryBoard can definitely have, as its first task, a spec task that points to a review in the nova-specs repository. When that task is completed (i.e. the change to nova-specs is merged), you should add additional tasks to that feature story, corresponding to implementation. That keeps the approval workflows in Gerrit (be it at design or implementation level) and uses StoryBoard to link all the things together (which is its main feature). -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
Doug Hellmann wrote: Other projects up to try it? The only possible addition is that we might need to work out is cross-project blueprints and which repo should those live in? We're doing well on integration, be careful about siloing. TBH tracking cross-project blueprint impact is a problem *today*, typically we end up with either only one of the involved projects having a blueprint for the feature or all of them having one (if you are lucky they might at least link to the same design on the wiki but often not ;)). I am hoping that is something that can ultimately be addressed in storyboard but am unsure of how we would resolve that as part of this proposal, unless instead you had a central blueprint repository and used a tag in the review to indicate which projects are impacted/involved? A central repository does have a certain appeal, especially from my perspective in Oslo where the work that we do will have an increasing impact on the projects that consume the libraries. It makes review permissions on the designs a little tricky, but I think we can work that out with agreements rather than having to enforce it in gerrit. Yes, the main drawback of the nova-specs repository is that it perpetuates a project-centric view of features. StoryBoard will enable tracking of cross-project features (the same way Launchpad bugs can have tasks affecting multiple projects). So if this idea sticks, it would be nice to have a solution for approval of cross-project specs in the future. In the mean time this is not a blocker to experimentation. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On 6 March 2014 19:09, Russell Bryant rbry...@redhat.com wrote: On 03/06/2014 01:05 PM, Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. We certainly did better this cycle. Having a team of people do the reviews helped. We have some criteria documented [1]. Trying to do reviews the blueprint whiteboard is just a painful disaster of a workflow. +1 Se have improved this, but there were two key issues: * lots of blueprints still approved from before we started this * not relaying having tools to track what has happened In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. I am a *HUGE* fan of the general idea. It's a tool we already use for review and iterating on text. It seems like it would be a huge win. I also think it would allow and encourage a lot more people to get involved in the reviews. I like the idea of iterating in gerrit until it's approved, and then using blueprints to track status throughout development. We could copy the text back into the blueprint, or just have a link to the proper file in the git repo. +1 I think a dedicated git repo for this makes sense. openstack/nova-blueprints or something, or openstack/nova-proposals if we want to be a bit less tied to launchpad terminology. +1 It would be good to have the reviews done my nova-core. We can leave nova-drivers (for the moment) for priority setting, etc. If folks are on board with the idea, I'm happy to work on getting a repo set up. The base template could be the first review against the repo. Sounds cool. We probably need a mass un-approve of all the blueprints in Nova, so all new blueprints in Juno go through the new process. I can take charge of that part, and helping with joining some of the dots and testing this out. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On 7 March 2014 19:50, Tim Bell tim.b...@cern.ch wrote: The recent operator gathering (https://etherpad.openstack.org/p/operators-feedback-mar14) concluded a similar proposal, based on Blueprint-on-Blueprints (BoB for short). The aim was that operators of production OpenStack clouds should engage to give input at an early stage - Raising concerns at the specification stage will be much more productive than after the code is written - Operators may not have the in-depth python skills for productive participation in the later stages of the review - Appropriate credit can also be granted to those people refining the requirements/specification process. Spotting an issue before coding starts is a major contribution. The sort of items we were worrying about were: Monitoring Metrics Alerts Health check/http ping Logging Lifecycle HA test upgrade roll-back restart Documentation object state/flow usage debug We also need to review the weighting. A blueprint should not be indefinitely postponed due to a differing view on requirements between new function and the ability to run the existing environments. I am really keen to find a way to make this work. I worry that getting operators to review all blueprints is not very scalable. Although having a process where thats possible seems like a good way to testing that out. Getting specific pain points is clearly important. Sometimes thats bugs, sometimes that features. But I wonder if we can agree more general themes that can help inform our priority setting of bugs and blueprints. Back in San Deigo or San Francisco (?) I remember a good summit session where we got lots of concrete pain points back from Ops guys who were in the room. Making that a regular feature might be useful, if we can use that session to tune some general priorities for the following cycle. For example, not worried about X, what really kills me is the lack of A and that B really sucks. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On 03/10/2014 08:20 AM, John Garbutt wrote: We probably need a mass un-approve of all the blueprints in Nova, so all new blueprints in Juno go through the new process. I can take charge of that part, and helping with joining some of the dots and testing this out. Sounds great. I do think we should move forward here. +1 to forcing all Juno to go through this. Thanks for going through all the launchpad blueprints. Next up will be to get the repo created. I'll look into that part. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On 03/10/2014 11:41 AM, Russell Bryant wrote: On 03/10/2014 08:20 AM, John Garbutt wrote: We probably need a mass un-approve of all the blueprints in Nova, so all new blueprints in Juno go through the new process. I can take charge of that part, and helping with joining some of the dots and testing this out. Sounds great. I do think we should move forward here. +1 to forcing all Juno to go through this. Thanks for going through all the launchpad blueprints. Next up will be to get the repo created. I'll look into that part. openstack-infra/config patch for creating the repo: https://review.openstack.org/#/c/79363/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
Sean Dague said on Thu, Mar 06, 2014 at 01:05:15PM -0500: The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. +1 to the idea. Would it be useful to require a single bp for changes to contended files, EG the ComputeNode class definition? If the fields to be added had been agreed up-front, some considerable rebasing could have been avoided. Alexis -- Nova Engineer, HP Cloud. AKA lealexis, lxsli. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Thu, Mar 06, 2014 at 01:05:15PM -0500, Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. As someone who has complained about the awfulness of our blueprint design docs process many times, I'd welcome this effort to ensure that we actually do detailed review. In concert with this I'd suggest that we setup some kind of bot that would automatically add a -2 to any patch which is submitted where the linked blueprint is not already approved. This would make it very clear to people who just submit patches and create a blueprint just as a tick box for process compliance, that they're doing it wrong. It would also make it clear to reviewers that they shouldn't waste their time on patches which are not approved. 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. Sounds like an interesting experiment, and a timely one as we figure out how to do blueprint approval in the future with StoryBoard. I'm a bit skeptical that can work without enforcing that changes reference at least a bug or a blueprint, though. People who were too lazy to create a single-sentence blueprint to cover for their feature will definitely not go through a Gerrit-powered process, so the temptation to fly your smallish features below the radar (not worth this whole blueprint approval thing) and just get them merged will be high. I fear it will overall result in work being less tracked, rather than more tracked. FWIW we plan to enforce a bug reference / blueprint reference in changes with StoryBoard, but it comes with autocreation of missing bugs/blueprints (from the commit message) to lower the developer hassle. That being said, don't let my skepticism go into the way of your experimentation. We definitely need to improve in this area. I'd like to have a cross-project session on feature planning/tracking at the Design Summit, where we can brainstorm more ideas around this. -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Fri, Mar 07, 2014 at 12:30:15PM +0100, Thierry Carrez wrote: Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. Sounds like an interesting experiment, and a timely one as we figure out how to do blueprint approval in the future with StoryBoard. I'm a bit skeptical that can work without enforcing that changes reference at least a bug or a blueprint, though. People who were too lazy to create a single-sentence blueprint to cover for their feature will definitely not go through a Gerrit-powered process, so the temptation to fly your smallish features below the radar (not worth this whole blueprint approval thing) and just get them merged will be high. I fear it will overall result in work being less tracked, rather than more tracked. It is fairly easy to spot when people submit things which are features, without a blueprint or bug listed. So as long as reviewers make a god habit of rejecting such patches I think people will get the message fairly quickly. FWIW we plan to enforce a bug reference / blueprint reference in changes with StoryBoard, but it comes with autocreation of missing bugs/blueprints (from the commit message) to lower the developer hassle. That being said, don't let my skepticism go into the way of your experimentation. We definitely need to improve in this area. I'd like to have a cross-project session on feature planning/tracking at the Design Summit, where we can brainstorm more ideas around this. If nothing else, trying more formal review of blueprints in gerrit for a cycle, should teach us more about what we'll want storyboard to be able todo in this area. 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On 03/07/2014 06:30 AM, Thierry Carrez wrote: Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. Sounds like an interesting experiment, and a timely one as we figure out how to do blueprint approval in the future with StoryBoard. I'm a bit skeptical that can work without enforcing that changes reference at least a bug or a blueprint, though. People who were too lazy to create a single-sentence blueprint to cover for their feature will definitely not go through a Gerrit-powered process, so the temptation to fly your smallish features below the radar (not worth this whole blueprint approval thing) and just get them merged will be high. I fear it will overall result in work being less tracked, rather than more tracked. FWIW we plan to enforce a bug reference / blueprint reference in changes with StoryBoard, but it comes with autocreation of missing bugs/blueprints (from the commit message) to lower the developer hassle. That being said, don't let my skepticism go into the way of your experimentation. We definitely need to improve in this area. I'd like to have a cross-project session on feature planning/tracking at the Design Summit, where we can brainstorm more ideas around this. Honestly, right now we're not trying to fix all things (or enforce all things). We're trying to fix a very specific issue that because we are tool-failing on blueprint approval, as it's entirely impossible to have a detailed conversation in launchpad, we're failing open with a bunch of approved and targeted blueprints that no one understands what they are. I want StoryBoard more than anyone else. However future Puppies and Unicorns don't fix real problems right now. With the tools already at our disposal, just using them a different way, I think we can fix some real problems. I think, more importantly, we're going to discover a whole new class of problems because we're not blocked on launchpad. And the fact that the Nova team and the Ops team came up with the same idea, independently, within a week of each other, is a reasonable indication that it's worth trying. Because it seriously can't be worse than the current model. :) -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
The principle is excellent, I think there are two points/objectives worth keeping in mind: 1. We need an effective way to make and record the design decisions 2. We should make the whole development process easier In my mind the point of the design review part is to agree up front something that should not be over-turned (or is hard to over-turn) late in patch review. I agree with others that a patch should not be blocked (or should be hard to block) because the reviewer disagrees with an agreed design decision. Perhaps an author can ask for a -2 or -1 to be removed if they can point out the agreed design decision, without having to reopen the debate. I also think that blueprints tend to have parts that should be agreed up front, like changes to apis, database migrations, or integration points in general. They also have parts that don't need to be agreed up front, there is no point in a heavyweight process for everything. Some blueprints might not need any of this at all. For example, a new plugin for the filter scheduler might no need a lot of design review, or at least, adding the design review is unlikely to ease the development cycle. So, we could use the blueprint template to identify things that need to be agreed in the design review. These could include anything the proposer wants agreed up front and possibly specifics of a defined set of integration points. Some blueprints might have nothing to be formally agreed in design review. Additionally, sometimes plans change, so it should be possible to return to design review. Possibly the notion of a design decision could be broken out form a blueprint in the same way as a patch-set? maybe it only makes sense to do it as a whole? Certainly design decisions should be made in relation to other blueprints and so it should be easy to see that there are two blueprints making related design decisions. The main point is that there should be an identifiable set of design decisions that have reviewed and agreed that can also be found. **The reward for authors in doing this is the author can defend their patch-set against late objections to design decisions.** **The reward for reviewers is they get a way to know what has been agreed in relation to a blueprint.** On another point... ...sometimes I fall foul of writing code using an approach I have seen in the code base, only to be told it was decided not to do it that way anymore. Sometimes I had no way of knowing that, and exactly what has been decided, when it was decided, and who did the deciding has been lost. Clearly the PTL and ML do help out here, but it would be helpful if such things were easy to find out. These kinds of design decision should be reviewed and recorded. Again, I think it is excellent that this is being addressed. Paul. -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: 07 March 2014 12:01 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval On 03/07/2014 06:30 AM, Thierry Carrez wrote: Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Mar 6, 2014 1:11 PM, Sean Dague s...@dague.net wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'm very much in favor of this idea. One of the topics we discussed at the OpenStack Operator day this week was just this problem. The lack of alerts/notification of new blueprint creation and the lack of insight into design architecture, feedback, and approval of them. There are many cases where Operators would like to provide feedback to the design process of new features early on to ensure upgrade compatibility, scale, security, HA, and other issues of concern to Operators. This would be a great way to get them more involved in the process. Nate ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
- Original Message - On Thu, Mar 6, 2014 at 12:05 PM, Sean Dague s...@dague.net wrote: I think this is really worthwhile to try -- and it might offer an interesting, readable history of decisions made. Plus how funny it was also brought up at the Ops Summit. Convergence, cool. It also goes along with our hope to move API design docs into the repo. Other projects up to try it? The only possible addition is that we might need to work out is cross-project blueprints and which repo should those live in? We're doing well on integration, be careful about siloing. Anne TBH tracking cross-project blueprint impact is a problem *today*, typically we end up with either only one of the involved projects having a blueprint for the feature or all of them having one (if you are lucky they might at least link to the same design on the wiki but often not ;)). I am hoping that is something that can ultimately be addressed in storyboard but am unsure of how we would resolve that as part of this proposal, unless instead you had a central blueprint repository and used a tag in the review to indicate which projects are impacted/involved? Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
Yep, great idea. Do it. On 03/07/2014 02:53 AM, Chris Behrens wrote: On Mar 6, 2014, at 11:09 AM, Russell Bryant rbry...@redhat.com wrote: […] I think a dedicated git repo for this makes sense. openstack/nova-blueprints or something, or openstack/nova-proposals if we want to be a bit less tied to launchpad terminology. +1 to this whole idea.. and we definitely should have a dedicated repo for this. I’m indifferent to its name. :) Either one of those works for me. - Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Fri, Mar 7, 2014 at 10:47 AM, Steve Gordon sgor...@redhat.com wrote: - Original Message - On Thu, Mar 6, 2014 at 12:05 PM, Sean Dague s...@dague.net wrote: I think this is really worthwhile to try -- and it might offer an interesting, readable history of decisions made. Plus how funny it was also brought up at the Ops Summit. Convergence, cool. It also goes along with our hope to move API design docs into the repo. Other projects up to try it? The only possible addition is that we might need to work out is cross-project blueprints and which repo should those live in? We're doing well on integration, be careful about siloing. Anne TBH tracking cross-project blueprint impact is a problem *today*, typically we end up with either only one of the involved projects having a blueprint for the feature or all of them having one (if you are lucky they might at least link to the same design on the wiki but often not ;)). I am hoping that is something that can ultimately be addressed in storyboard but am unsure of how we would resolve that as part of this proposal, unless instead you had a central blueprint repository and used a tag in the review to indicate which projects are impacted/involved? A central repository does have a certain appeal, especially from my perspective in Oslo where the work that we do will have an increasing impact on the projects that consume the libraries. It makes review permissions on the designs a little tricky, but I think we can work that out with agreements rather than having to enforce it in gerrit. Doug Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On 2014-03-06 18:16, Christopher Yeoh wrote: On Thu, 06 Mar 2014 13:05:15 -0500 Sean Dague s...@dague.net wrote: In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) +1. I think this could really help avoid wasted work for API related changes in particular. Just wondering if we need step 4 - or if the blueprint text should always just link to either the unapproved patch for the text in gerrit, or the text in repository once it's approved. Updates to proposal would be proposed through the same process. Chris It makes sense to me to have whatever was approved in Gerrit be the canonical version. Copy-pasting back to launchpad seems error prone. IIRC, blueprints have a field for a link to the spec, so maybe we should just link to the Gerrit content with that? It would be nice to have a bot that can update bp status and such when a change is approved in Gerrit, but that's something that can happen in the future. -Ben ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
The recent operator gathering (https://etherpad.openstack.org/p/operators-feedback-mar14) concluded a similar proposal, based on Blueprint-on-Blueprints (BoB for short). The aim was that operators of production OpenStack clouds should engage to give input at an early stage - Raising concerns at the specification stage will be much more productive than after the code is written - Operators may not have the in-depth python skills for productive participation in the later stages of the review - Appropriate credit can also be granted to those people refining the requirements/specification process. Spotting an issue before coding starts is a major contribution. The sort of items we were worrying about were: Monitoring Metrics Alerts Health check/http ping Logging Lifecycle HA test upgrade roll-back restart Documentation object state/flow usage debug We also need to review the weighting. A blueprint should not be indefinitely postponed due to a differing view on requirements between new function and the ability to run the existing environments. Tim -Original Message- From: Murray, Paul (HP Cloud Services) [mailto:pmur...@hp.com] Sent: 07 March 2014 14:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval The principle is excellent, I think there are two points/objectives worth keeping in mind: 1. We need an effective way to make and record the design decisions 2. We should make the whole development process easier In my mind the point of the design review part is to agree up front something that should not be over-turned (or is hard to over-turn) late in patch review. I agree with others that a patch should not be blocked (or should be hard to block) because the reviewer disagrees with an agreed design decision. Perhaps an author can ask for a -2 or -1 to be removed if they can point out the agreed design decision, without having to reopen the debate. I also think that blueprints tend to have parts that should be agreed up front, like changes to apis, database migrations, or integration points in general. They also have parts that don't need to be agreed up front, there is no point in a heavyweight process for everything. Some blueprints might not need any of this at all. For example, a new plugin for the filter scheduler might no need a lot of design review, or at least, adding the design review is unlikely to ease the development cycle. So, we could use the blueprint template to identify things that need to be agreed in the design review. These could include anything the proposer wants agreed up front and possibly specifics of a defined set of integration points. Some blueprints might have nothing to be formally agreed in design review. Additionally, sometimes plans change, so it should be possible to return to design review. Possibly the notion of a design decision could be broken out form a blueprint in the same way as a patch-set? maybe it only makes sense to do it as a whole? Certainly design decisions should be made in relation to other blueprints and so it should be easy to see that there are two blueprints making related design decisions. The main point is that there should be an identifiable set of design decisions that have reviewed and agreed that can also be found. **The reward for authors in doing this is the author can defend their patch-set against late objections to design decisions.** **The reward for reviewers is they get a way to know what has been agreed in relation to a blueprint.** On another point... ...sometimes I fall foul of writing code using an approach I have seen in the code base, only to be told it was decided not to do it that way anymore. Sometimes I had no way of knowing that, and exactly what has been decided, when it was decided, and who did the deciding has been lost. Clearly the PTL and ML do help out here, but it would be helpful if such things were easy to find out. These kinds of design decision should be reviewed and recorded. Again, I think it is excellent that this is being addressed. Paul. -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: 07 March 2014 12:01 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval On 03/07/2014 06:30 AM, Thierry Carrez wrote: Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review
[openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
Hey Sean, The number one item that came out of the Operator's mini summit on Monday was better mechanisms to engage Operators in the design and review process. Moving Blueprints to Gerrit was something discussed quite a bit. It's fantastic to hear the same thing is coming from the Nova development side as well. It also allows for Operators to get some credit for participating within the community. I can's speak for all, but I can say that based on the discussion in the room there is good support for this from those of us that have to run OpenStack on a daily basis. Please let me know how we can help move this change along. Thanks! Matt On 3/6/14 12:05 PM, Sean Dague s...@dague.net wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Thursday, March 6, 2014 at 11:09 AM, Russell Bryant wrote: On 03/06/2014 01:05 PM, Sean Dague wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. We certainly did better this cycle. Having a team of people do the reviews helped. We have some criteria documented [1]. Trying to do reviews the blueprint whiteboard is just a painful disaster of a workflow. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. I am a *HUGE* fan of the general idea. It's a tool we already use for review and iterating on text. It seems like it would be a huge win. I also think it would allow and encourage a lot more people to get involved in the reviews. I like the idea of iterating in gerrit until it's approved, and then using blueprints to track status throughout development. We could copy the text back into the blueprint, or just have a link to the proper file in the git repo. I think a dedicated git repo for this makes sense. openstack/nova-blueprints or something, or openstack/nova-proposals if we want to be a bit less tied to launchpad terminology. If folks are on board with the idea, I'm happy to work on getting a repo set up. The base template could be the first review against the repo. [1] https://wiki.openstack.org/wiki/Blueprints Funny, we actually had this very recommendation come out of the OpenStack Operators mini-summit this week. There are other people very interested in this approach for blueprints. John -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Thu, 06 Mar 2014 13:05:15 -0500 Sean Dague s...@dague.net wrote: In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) +1. I think this could really help avoid wasted work for API related changes in particular. Just wondering if we need step 4 - or if the blueprint text should always just link to either the unapproved patch for the text in gerrit, or the text in repository once it's approved. Updates to proposal would be proposed through the same process. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
This is TRULY a constructive suggestion. Time and again people have good ideas, but fail to make them high-quality BPs, even being familiar with code base. The major reason lies in lacking of design experiences. Such a Gerrit-based design iteration will make the design and decision process more productive, leading to high quality design outputs in earlier phases of work. Beyond the text/template format thing, several high-quality BP examples can be recommended, by core members, as references to follow. Especially those BPs have a brief and concrete summary, a descriptive and detailed wiki page and are finally approved and merged. Some analysis and comments could be added to highlight the excellence and value of those recommended BPs. Thanks, Sean, for your suggestion! A BIG +1 -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: Friday, March 07, 2014 2:05 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
+1, we also need some work to clean existing blueprints which are not approved. I think that is responsibility for drafter of those blueprints to follow new process. 2014-03-07 2:05 GMT+08:00 Sean Dague s...@dague.net: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ChangBo Guo(gcb) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
+1 Agree with you. I like this idea so much. It makes the blueprint review/discuss better tracked and recorded. It's convenient for the people joining later to know the design's history. -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: Friday, March 07, 2014 2:05 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
+1 Agree with you. I like this idea so much. It makes the blueprint review/discuss better tracked and recorded. It's convenient for the people joining later to know the design's history. -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: Friday, March 07, 2014 2:05 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Thu, Mar 6, 2014 at 12:05 PM, Sean Dague s...@dague.net wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint or create a good one with a great template! 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. I think this is really worthwhile to try -- and it might offer an interesting, readable history of decisions made. Plus how funny it was also brought up at the Ops Summit. Convergence, cool. It also goes along with our hope to move API design docs into the repo. Other projects up to try it? The only possible addition is that we might need to work out is cross-project blueprints and which repo should those live in? We're doing well on integration, be careful about siloing. Anne * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Mar 6, 2014, at 11:09 AM, Russell Bryant rbry...@redhat.com wrote: […] I think a dedicated git repo for this makes sense. openstack/nova-blueprints or something, or openstack/nova-proposals if we want to be a bit less tied to launchpad terminology. +1 to this whole idea.. and we definitely should have a dedicated repo for this. I’m indifferent to its name. :) Either one of those works for me. - Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
