Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval

2014-03-17 Thread Thierry Carrez
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

2014-03-17 Thread Thierry Carrez
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

2014-03-10 Thread John Garbutt
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

2014-03-10 Thread John Garbutt
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

2014-03-10 Thread Russell Bryant
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

2014-03-10 Thread Russell Bryant
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

2014-03-07 Thread Alexis Lee
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

2014-03-07 Thread Daniel P. Berrange
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

2014-03-07 Thread Thierry Carrez
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

2014-03-07 Thread Daniel P. Berrange
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

2014-03-07 Thread Sean Dague
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

2014-03-07 Thread Murray, Paul (HP Cloud Services)
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

2014-03-07 Thread Nathanael Burton
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

2014-03-07 Thread Steve Gordon
- 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

2014-03-07 Thread Sandy Walsh
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

2014-03-07 Thread Doug Hellmann
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

2014-03-07 Thread Ben Nemec

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

2014-03-07 Thread Tim Bell

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

Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval

2014-03-06 Thread Matt Van Winkle
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

2014-03-06 Thread Russell Bryant
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

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

2014-03-06 Thread John Dewey
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

2014-03-06 Thread Christopher Yeoh
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

2014-03-06 Thread zhangyu (AI)
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

2014-03-06 Thread ChangBo Guo
+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

2014-03-06 Thread Bohai (ricky)
+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

2014-03-06 Thread Liuji (Jeremy)
+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

2014-03-06 Thread Anne Gentle
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

2014-03-06 Thread Chris Behrens

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