Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-09-02 Thread Day, Phil
Adding in such case more bureaucracy (specs) is not the best way to resolve 
team throughput issues...

I’d argue that  if fundamental design disagreements can be surfaced and debated 
at the design stage rather than first emerging on patch set XXX of an 
implementation, and be used to then prioritize what needs to be implemented 
then they do have a useful role to play.

Phil


From: Boris Pavlovic [mailto:bpavlo...@mirantis.com]
Sent: 28 August 2014 23:13
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

Joe,


This is a resource problem, the nova team simply does not have enough people 
doing enough reviews to make this possible.

Adding in such case more bureaucracy (specs) is not the best way to resolve 
team throughput issues...

my 2cents


Best regards,
Boris Pavlovic

On Fri, Aug 29, 2014 at 2:01 AM, Joe Gordon 
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:


On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh 
alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com wrote:
I share Donald's points here, I believe what would help is to clearly describe 
in the Wiki the process and workflow for the BP approval process and build in 
this process how to deal with discrepancies/disagreements and build timeframes 
for each stage and process of appeal etc.
The current process would benefit from some fine tuning and helping to build 
safe guards and time limits/deadlines so folks can expect responses within a 
reasonable time and not be left waiting in the cold.


This is a resource problem, the nova team simply does not have enough people 
doing enough reviews to make this possible.

My 2cents!
/Alan

-Original Message-
From: Dugger, Donald D 
[mailto:donald.d.dug...@intel.commailto:donald.d.dug...@intel.com]
Sent: August-28-14 10:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

I would contend that that right there is an indication that there's a problem 
with the process.  You submit a BP and then you have no idea of what is 
happening and no way of addressing any issues.  If the priority is wrong I can 
explain why I think the priority should be higher, getting stonewalled leaves 
me with no idea what's wrong and no way to address any problems.

I think, in general, almost everyone is more than willing to adjust proposals 
based upon feedback.  Tell me what you think is wrong and I'll either explain 
why the proposal is correct or I'll change it to address the concerns.

Trying to deal with silence is really hard and really frustrating.  Especially 
given that we're not supposed to spam the mailing it's really hard to know what 
to do.  I don't know the solution but we need to do something.  More core team 
members would help, maybe something like an automatic timeout where BPs/patches 
with no negative scores and no activity for a week get flagged for special 
handling.

I feel we need to change the process somehow.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786tel:303%2F443-3786

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.commailto:jaypi...@gmail.com]
Sent: Thursday, August 28, 2014 1:44 PM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
 I'll try and not whine about my pet project but I do think there is a
 problem here.  For the Gantt project to split out the scheduler there
 is a crucial BP that needs to be implemented (
 https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP
 has been rejected and we'll have to try again for Kilo.  My question
 is did we do something wrong or is the process broken?

 Note that we originally proposed the BP on 4/23/14, went through 10
 iterations to the final version on 7/25/14 and the final version got
 three +1s and a +2 by 8/5.  Unfortunately, even after reaching out to
 specific people, we didn't get the second +2, hence the rejection.

 I understand that reviews are a burden and very hard but it seems
 wrong that a BP with multiple positive reviews and no negative reviews
 is dropped because of what looks like indifference.

I would posit that this is not actually indifference. The reason that there may 
not have been 1 +2 from a core team member may very well have been that the 
core team members did not feel that the blueprint's priority was high enough to 
put before other work, or that the core team members did have the time to 
comment on the spec (due to them not feeling the blueprint had the priority to 
justify the time to do a full review).

Note that I'm not a core drivers team member.

Best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev

Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-09-01 Thread Doug Hellmann

On Aug 29, 2014, at 5:07 AM, Thierry Carrez thie...@openstack.org wrote:

 Joe Gordon wrote:
 On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
 alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:
 
I share Donald's points here, I believe what would help is to
clearly describe in the Wiki the process and workflow for the BP
approval process and build in this process how to deal with
discrepancies/disagreements and build timeframes for each stage and
process of appeal etc.
The current process would benefit from some fine tuning and helping
to build safe guards and time limits/deadlines so folks can expect
responses within a reasonable time and not be left waiting in the cold.
 
 This is a resource problem, the nova team simply does not have enough
 people doing enough reviews to make this possible. 
 
 I think Nova lacks core reviewers more than it lacks reviewers, though.
 Just looking at the ratio of core developers vs. patchsets proposed,
 it's pretty clear that the core team is too small:
 
 Nova: 750 patchsets/month for 21 core = 36
 Heat: 230/14 = 16
 Swift: 50/16 = 3
 
 Neutron has the same issue (550/14 = 39). I think above 20, you have a
 dysfunctional setup. No amount of process, spec, or runway will solve
 that fundamental issue.
 
 The problem is, you can't just add core reviewers, they have to actually
 understand enough of the code base to be trusted with that +2 power. All
 potential candidates are probably already in. In Nova, the code base is
 so big it's difficult to find people that know enough of it. In Neutron,
 the contributors are often focused on subsections of the code base so
 they are not really interested in learning enough of the rest. That
 makes the pool of core candidates quite dry.
 
 I fear the only solution is smaller groups being experts on smaller
 codebases. There is less to review, and more candidates that are likely
 to be experts in this limited area.
 
 Applied to Nova, that means modularization -- having strong internal
 interfaces and trusting subteams to +2 the code they are experts on.
 Maybe VMWare driver people should just +2 VMware-related code. We've had
 that discussion before, and I know there is a dangerous potential
 quality slope there -- I just fail to see any other solution to bring
 that 750/21=36 figure down to a bearable level, before we burn out all
 of the Nova core team.

Besides making packaging and testing easier, one of the reasons Oslo uses a 
separate git repo for each of our libraries is to allow this sort of 
specialization. We have a core group with +2 across all of the libraries, and 
we have some team members who only have +2 on one or two specific libraries 
where they focus their attention.

Doug

 
 -- 
 Thierry Carrez (ttx)
 
 ___
 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] Is the BP approval process broken?

2014-08-31 Thread Dugger, Donald D
Indeed, this is pretty much what we are going to do about Gantt.  Nobody has 
said don’t do it, all of the objections have been around how  when to do the 
split.  We will revisit in Kilo (hopefully early in the cycle) and try again.

Note there is still the issue of Nova BP review process that I think needs to 
be tweaked but that is separate from the issue of how do we get Gantt going.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: Friday, August 29, 2014 8:39 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?


On Aug 29, 2014 10:42 AM, Dugger, Donald D 
donald.d.dug...@intel.commailto:donald.d.dug...@intel.com wrote:

 Well, I think that there is a sign of a broken (or at least bent) process and 
 that's what I'm trying to expose.  Especially given the ongoing conversations 
 over Gantt it seems wrong that ultimately it was rejected due to silence.  
 Maybe rejecting the BP was the right decision but the way the decision was 
 made was just wrong.

 Note that dealing with silence is `really` difficult.  You point out that 
 maybe silence means people don't agree with the BP but how do I know?  Maybe 
 it means no one has time, maybe no one has an opinion, maybe it got lost in 
 the shuffle, maybe I'm being too obnoxious - who knows.  A simple -1 with a 
 one sentence explanation would helped a lot.

How is this:

-1, we already have too many approved blueprints in Juno and it sounds like 
there are still concerns about the Gantt split in general. Hopefully after 
trunk is open for Kilo we can revisit the Gantt idea. I'm thinking yet another 
ML thread outlining why and how to get there.


 --
 Don Dugger
 Censeo Toto nos in Kansa esse decisse. - D. Gale
 Ph: 303/443-3786

 -Original Message-
 From: Jay Pipes [mailto:jaypi...@gmail.commailto:jaypi...@gmail.com]
 Sent: Friday, August 29, 2014 10:43 AM
 To: 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

 On 08/29/2014 12:25 PM, Zane Bitter wrote:
  On 28/08/14 17:02, Jay Pipes wrote:
  I understand your frustration about the silence, but the silence from
  core team members may actually be a loud statement about where their
  priorities are.
 
  I don't know enough about the Nova review situation to say if the
  process is broken or not. But I can say that if passive-aggressively
  ignoring people is considered a primary communication channel,
  something is definitely broken.

 Nobody is ignoring anyone. There have ongoing conversations about the 
 scheduler and Gantt, and those conversations haven't resulted in all the 
 decisions that Don would like. That is unfortunate, but it's not a sign of a 
 broken process.

 -jay


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto: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] Is the BP approval process broken?

2014-08-29 Thread Thierry Carrez
Joe Gordon wrote:
 On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
 alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:
 
 I share Donald's points here, I believe what would help is to
 clearly describe in the Wiki the process and workflow for the BP
 approval process and build in this process how to deal with
 discrepancies/disagreements and build timeframes for each stage and
 process of appeal etc.
 The current process would benefit from some fine tuning and helping
 to build safe guards and time limits/deadlines so folks can expect
 responses within a reasonable time and not be left waiting in the cold.
 
 This is a resource problem, the nova team simply does not have enough
 people doing enough reviews to make this possible. 

I think Nova lacks core reviewers more than it lacks reviewers, though.
Just looking at the ratio of core developers vs. patchsets proposed,
it's pretty clear that the core team is too small:

Nova: 750 patchsets/month for 21 core = 36
Heat: 230/14 = 16
Swift: 50/16 = 3

Neutron has the same issue (550/14 = 39). I think above 20, you have a
dysfunctional setup. No amount of process, spec, or runway will solve
that fundamental issue.

The problem is, you can't just add core reviewers, they have to actually
understand enough of the code base to be trusted with that +2 power. All
potential candidates are probably already in. In Nova, the code base is
so big it's difficult to find people that know enough of it. In Neutron,
the contributors are often focused on subsections of the code base so
they are not really interested in learning enough of the rest. That
makes the pool of core candidates quite dry.

I fear the only solution is smaller groups being experts on smaller
codebases. There is less to review, and more candidates that are likely
to be experts in this limited area.

Applied to Nova, that means modularization -- having strong internal
interfaces and trusting subteams to +2 the code they are experts on.
Maybe VMWare driver people should just +2 VMware-related code. We've had
that discussion before, and I know there is a dangerous potential
quality slope there -- I just fail to see any other solution to bring
that 750/21=36 figure down to a bearable level, before we burn out all
of the Nova core team.

-- 
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] Is the BP approval process broken?

2014-08-29 Thread Daniel P. Berrange
On Thu, Aug 28, 2014 at 03:44:25PM -0400, Jay Pipes wrote:
 On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
 I’ll try and not whine about my pet project but I do think there is a
 problem here.  For the Gantt project to split out the scheduler there is
 a crucial BP that needs to be implemented (
 https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP has
 been rejected and we’ll have to try again for Kilo.  My question is did
 we do something wrong or is the process broken?
 
 Note that we originally proposed the BP on 4/23/14, went through 10
 iterations to the final version on 7/25/14 and the final version got
 three +1s and a +2 by 8/5.  Unfortunately, even after reaching out to
 specific people, we didn’t get the second +2, hence the rejection.
 
 I understand that reviews are a burden and very hard but it seems wrong
 that a BP with multiple positive reviews and no negative reviews is
 dropped because of what looks like indifference.
 
 I would posit that this is not actually indifference. The reason that there
 may not have been 1 +2 from a core team member may very well have been that
 the core team members did not feel that the blueprint's priority was high
 enough to put before other work, or that the core team members did have the
 time to comment on the spec (due to them not feeling the blueprint had the
 priority to justify the time to do a full review).

That is fine from the POV of a general blueprint. In this case though
we explicitly approved an exception to the freeze for this blueprint.
This (w|sh)ould only have been done if we considered it high enough
priority and with a commitment to actually review it.  ie we should
not approve exceptions to freeze dates for things we don't care about.

 Note that I'm not a core drivers team member.

Which I think is an issue in itself. With all the problems we have
with review bandwidth, the idea that we should pick an even smaller
subset of 'nova core' to form a 'nova drivers' group is broken. I
was rather suprised myself when I first learnt that 'nova drivers'
even existed (by finding I could not +2 specs). I was lucky that
Mikal proposed to add me to nova drivers, so it ultimately didn't
impact me. Looking at nova core though, I really don't see why some
members of nova core should be privileged in reviewing  approving
specs, over others. IMHO, the idea of the smaller nova drivers group
should die and everyone in nova core should share that responsibility.

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] Is the BP approval process broken?

2014-08-29 Thread Daniel P. Berrange
On Thu, Aug 28, 2014 at 04:27:59PM -0600, Chris Friesen wrote:
 On 08/28/2014 04:01 PM, Joe Gordon wrote:
 
 
 
 On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
 alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:
 
 I share Donald's points here, I believe what would help is to
 clearly describe in the Wiki the process and workflow for the BP
 approval process and build in this process how to deal with
 discrepancies/disagreements and build timeframes for each stage and
 process of appeal etc.
 The current process would benefit from some fine tuning and helping
 to build safe guards and time limits/deadlines so folks can expect
 responses within a reasonable time and not be left waiting in the cold.
 
 
 This is a resource problem, the nova team simply does not have enough
 people doing enough reviews to make this possible.
 
 All the more reason to make it obvious which reviews are not being addressed
 in a timely fashion.  (I'm thinking something akin to the order screen at a
 fast food restaurant that starts blinking in red and beeping if an order
 hasn't been filled in a certain amount of time.)

This information can easily be queried from gerrit. I proposed last week that
core team members should especially look for reviews which have one +2 already,
as being items that are potentially approvable and thus should not be left to
lie idle for a long time

  http://lists.openstack.org/pipermail/openstack-dev/2014-August/043657.html

There are a variety of other ways/criteria to query lists of changes which
I outline with the gerrymander tool

  http://lists.openstack.org/pipermail/openstack-dev/2014-August/043085.html

 Perhaps by making it clear that reviews are a bottleneck this will actually
 help to address the problem.

We have the tools / capabilities for this already. The problems are whether
people effectively use the tools to priortize their work, and whether we
even have enough review bandwidth at all.

I'm certain though that this schedular review should not have got lost
in the way it did.

I'd like to see the core team set a firm target that a review with one +2
and no -1s, should not be allowed to languish for more than 1 week, with
out having either a second +2 or a -1 (unless it is blocked by a change
it depends on).

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] Is the BP approval process broken?

2014-08-29 Thread Daniel P. Berrange
On Fri, Aug 29, 2014 at 11:07:33AM +0200, Thierry Carrez wrote:
 Joe Gordon wrote:
  On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
  alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:
  
  I share Donald's points here, I believe what would help is to
  clearly describe in the Wiki the process and workflow for the BP
  approval process and build in this process how to deal with
  discrepancies/disagreements and build timeframes for each stage and
  process of appeal etc.
  The current process would benefit from some fine tuning and helping
  to build safe guards and time limits/deadlines so folks can expect
  responses within a reasonable time and not be left waiting in the cold.
  
  This is a resource problem, the nova team simply does not have enough
  people doing enough reviews to make this possible. 
 
 I think Nova lacks core reviewers more than it lacks reviewers, though.
 Just looking at the ratio of core developers vs. patchsets proposed,
 it's pretty clear that the core team is too small:
 
 Nova: 750 patchsets/month for 21 core = 36
 Heat: 230/14 = 16
 Swift: 50/16 = 3
 
 Neutron has the same issue (550/14 = 39). I think above 20, you have a
 dysfunctional setup. No amount of process, spec, or runway will solve
 that fundamental issue.
 
 The problem is, you can't just add core reviewers, they have to actually
 understand enough of the code base to be trusted with that +2 power. All
 potential candidates are probably already in. In Nova, the code base is
 so big it's difficult to find people that know enough of it. In Neutron,
 the contributors are often focused on subsections of the code base so
 they are not really interested in learning enough of the rest. That
 makes the pool of core candidates quite dry.
 
 I fear the only solution is smaller groups being experts on smaller
 codebases. There is less to review, and more candidates that are likely
 to be experts in this limited area.
 
 Applied to Nova, that means modularization -- having strong internal
 interfaces and trusting subteams to +2 the code they are experts on.
 Maybe VMWare driver people should just +2 VMware-related code. We've had
 that discussion before, and I know there is a dangerous potential
 quality slope there -- I just fail to see any other solution to bring
 that 750/21=36 figure down to a bearable level, before we burn out all
 of the Nova core team.

I broadly agree - I think that unless Nova moves more towards something
that is closer to the Linux style subsystem maintainer model we are 
doomed. I know in Linux, the maintainers actually use separate git trees,
and that isn't what I mean - I think using a single git tree is still
desirable (at least for now). What I mean is that we should place more
trust on the opinion of the people who are experts for a particular
area of code. Let those experts take on a greater burden of the code
review so core team can put more focus on actual merge approval.

I know some of the core team try to do this implicitly - eg we know who
some of the main people involved in hyperv or vmware are, so will tend
to treat their +1 as an effective +2 from the POV of their driver code,
but our rules still require two actual +2s from core, so it doesn't
entirely help us right now. I think we need to do some work in tooling
to make this more of an explicit process though.

The problem is that gerrit does not allow us to say person X has +2 for
code that touches directory path /foo/bar. The +2 is global to the entire
repository. We could try to deal with this problem outside of gerrit
though. As a starting point, each virt driver (or major functional area
of nova codebase) should have an explicit list of people who are considered
to be the core team for that area of code.  From such a list, tools like
gerrymander (or anything else that can query gerrit), could see when a
person in those lists +1'd a change touching their area of responsibility
and change that to be presented as a +1.5.

This would make it very explicit to the reviewers that they should consider
the change to be (almost) equivalent to a +2.  We could potentially then
relax the rule of

 +A requires two +2s

to be 

 +A requires (two +2s) or (one +2 and one +1.5)

I think this would significantly improve our review throughput. I think
it could also help us get people to gain greater responsibility. The
jump from regular contributor to core team member is quite a high bar.
If we had the intermediate step of subsystem team member that would ease
the progression. It would also give the subsystem teams a greater sense
of engagement  value in the nova community

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-   

Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread John Garbutt
Going a bit further up the thread where we are still talking about
spec reviews and not code reviews...

On 28 August 2014 21:42, Dugger, Donald D donald.d.dug...@intel.com wrote:
 I would contend that that right there is an indication that there's a problem 
 with the process.

We got two nova-core reviewer sponsors, to ensure the code would get
reviewed before FF.

We probably should have got two nova-driver sponsors for a spec
freeze. The cores don't have +2 in spec land.

This is the first release we are doing specs, so there are likely to
be holes in the process. I think next time we could try two nova-cores
and two nova-drivers (the driver might sign up for the spec review,
but not the code review).

Also, the spec only got an exception for one week only. I was very
late on adding the -2, apologies. I just spotted it was missed out,
when doing a bit of house keeping for juno-3.

 You submit a BP and then you have no idea of what is happening and no way of 
 addressing any issues.  If the priority is wrong I can explain why I think 
 the priority should be higher, getting stonewalled leaves me with no idea 
 what's wrong and no way to address any problems.

Feel free to raise this in the nova-meeting, or ping me or mikal on
IRC or via email.

 I think, in general, almost everyone is more than willing to adjust proposals 
 based upon feedback.  Tell me what you think is wrong and I'll either explain 
 why the proposal is correct or I'll change it to address the concerns.

Right. In this case, we just didn't get it reviewed. As mentioned,
probably because people didn't see this as important right now.

 Trying to deal with silence is really hard and really frustrating.  
 Especially given that we're not supposed to spam the mailing it's really hard 
 to know what to do.

For blueprint process stuff, email or catch me (johnthetubaguy) on
IRC, or mikal on IRC, or any of the nova-drivers. We can usually get
you an answer. Or generally ask people in #openstack-nova who should
be able to point you in the right direction.

I don't know the solution but we need to do something.  More core team members 
would help, maybe something like an automatic timeout where BPs/patches with 
no negative scores and no activity for a week get flagged for special handling.

We are brainstorming ideas for Kilo. But its always a balance. I don't
want to add extra red tape for every issue we have.

Right now we rely on people shouting on IRC if we forget really
important things, and fixing stuff up as required.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread John Garbutt
On 28 August 2014 21:58, Chris Friesen chris.frie...@windriver.com wrote:
 On 08/28/2014 02:25 PM, Jay Pipes wrote:
 On 08/28/2014 04:05 PM, Chris Friesen wrote:
 The overall scheduler-lib Blueprint is marked with a high priority
 at http://status.openstack.org/release/;.  Hopefully that would apply
 to sub-blueprints as well.

 a) There are no sub-blueprints to that scheduler-lib blueprint

 I guess my terminology was wrong.  The original email referred to
 https://review.openstack.org/#/c/89893/; as the crucial BP that needs to
 be implemented.  That is part of
 https://review.openstack.org/#/q/topic:bp/isolate-scheduler-db,n,z;, which
 is listed as a Gerrit topic in the scheduler-lib blueprint that I pointed
 out.

Yeah, its confusing. Those patches are meant for a different blueprint I assume.

 b) If there were sub-blueprints, that does not mean that they would
 necessarily take the same priority as their parent blueprint

 I'm not sure how that would work.  If we have a high-priority blueprint
 depending on work that is considered low-priority, that would seem to set up
 a classic priority inversion scenario.

What we do is this...

If something high priority depends on something low priority, the low
becomes high.
Or more often, they both become medium.

 c) There's no reason priorities can't be revisited when necessary

 Sure, but in that case it might be a good idea to make the updated priority
 explicit.

If something looks like it has the wrong priority, just ping me, or
one of the other nova-drivers, and we can discuss it. We did a bit of
that at the mid-cylce meet up.

Sometimes I just messed up, sometimes we didn't realise how important
it is, sometimes we need to explain why the other things are
considered more important right now.

Maybe what I said before, but if you see a problem, please shout up
ASAP, and lets get it sorted sooner, when its usually easier to sort
it.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread Zane Bitter

On 28/08/14 17:02, Jay Pipes wrote:

I understand your frustration about the silence, but the silence from
core team members may actually be a loud statement about where their
priorities are.


I don't know enough about the Nova review situation to say if the 
process is broken or not. But I can say that if passive-aggressively 
ignoring people is considered a primary communication channel, something 
is definitely broken.


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread Jay Pipes

On 08/29/2014 12:25 PM, Zane Bitter wrote:

On 28/08/14 17:02, Jay Pipes wrote:

I understand your frustration about the silence, but the silence from
core team members may actually be a loud statement about where their
priorities are.


I don't know enough about the Nova review situation to say if the
process is broken or not. But I can say that if passive-aggressively
ignoring people is considered a primary communication channel, something
is definitely broken.


Nobody is ignoring anyone. There have ongoing conversations about the 
scheduler and Gantt, and those conversations haven't resulted in all the 
decisions that Don would like. That is unfortunate, but it's not a sign 
of a broken process.


-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread Dugger, Donald D
Well, I think that there is a sign of a broken (or at least bent) process and 
that's what I'm trying to expose.  Especially given the ongoing conversations 
over Gantt it seems wrong that ultimately it was rejected due to silence.  
Maybe rejecting the BP was the right decision but the way the decision was made 
was just wrong.

Note that dealing with silence is `really` difficult.  You point out that maybe 
silence means people don't agree with the BP but how do I know?  Maybe it means 
no one has time, maybe no one has an opinion, maybe it got lost in the shuffle, 
maybe I'm being too obnoxious - who knows.  A simple -1 with a one sentence 
explanation would helped a lot.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Friday, August 29, 2014 10:43 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/29/2014 12:25 PM, Zane Bitter wrote:
 On 28/08/14 17:02, Jay Pipes wrote:
 I understand your frustration about the silence, but the silence from 
 core team members may actually be a loud statement about where their 
 priorities are.

 I don't know enough about the Nova review situation to say if the 
 process is broken or not. But I can say that if passive-aggressively 
 ignoring people is considered a primary communication channel, 
 something is definitely broken.

Nobody is ignoring anyone. There have ongoing conversations about the scheduler 
and Gantt, and those conversations haven't resulted in all the decisions that 
Don would like. That is unfortunate, but it's not a sign of a broken process.

-jay


___
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] Is the BP approval process broken?

2014-08-29 Thread Kevin Benton
I think the point is that if there were discussions that lead to
uncertainty about the split, they should have resulted in a - 1/-2 on the
spec instead of letting it sit there.
On Aug 29, 2014 9:46 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/29/2014 12:25 PM, Zane Bitter wrote:

 On 28/08/14 17:02, Jay Pipes wrote:

 I understand your frustration about the silence, but the silence from
 core team members may actually be a loud statement about where their
 priorities are.


 I don't know enough about the Nova review situation to say if the
 process is broken or not. But I can say that if passive-aggressively
 ignoring people is considered a primary communication channel, something
 is definitely broken.


 Nobody is ignoring anyone. There have ongoing conversations about the
 scheduler and Gantt, and those conversations haven't resulted in all the
 decisions that Don would like. That is unfortunate, but it's not a sign of
 a broken process.

 -jay


 ___
 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] Is the BP approval process broken?

2014-08-29 Thread John Garbutt
I think this is now more about code reviews, but this is important...

On 29 August 2014 10:30, Daniel P. Berrange berra...@redhat.com wrote:
 On Fri, Aug 29, 2014 at 11:07:33AM +0200, Thierry Carrez wrote:
 Joe Gordon wrote:
  On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
  alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:
 
  I share Donald's points here, I believe what would help is to
  clearly describe in the Wiki the process and workflow for the BP
  approval process and build in this process how to deal with
  discrepancies/disagreements and build timeframes for each stage and
  process of appeal etc.
  The current process would benefit from some fine tuning and helping
  to build safe guards and time limits/deadlines so folks can expect
  responses within a reasonable time and not be left waiting in the 
  cold.
 
  This is a resource problem, the nova team simply does not have enough
  people doing enough reviews to make this possible.

 I think Nova lacks core reviewers more than it lacks reviewers, though.
 Just looking at the ratio of core developers vs. patchsets proposed,
 it's pretty clear that the core team is too small:

 Nova: 750 patchsets/month for 21 core = 36
 Heat: 230/14 = 16
 Swift: 50/16 = 3

 Neutron has the same issue (550/14 = 39). I think above 20, you have a
 dysfunctional setup. No amount of process, spec, or runway will solve
 that fundamental issue.

+1

 The problem is, you can't just add core reviewers, they have to actually
 understand enough of the code base to be trusted with that +2 power. All
 potential candidates are probably already in. In Nova, the code base is
 so big it's difficult to find people that know enough of it. In Neutron,
 the contributors are often focused on subsections of the code base so
 they are not really interested in learning enough of the rest. That
 makes the pool of core candidates quite dry.

The other point is keeping the reviews consistent. Making the team
larger makes that harder.

If we did a better job of discussing core disagreements more in the
nova-meeting, maybe that would help keep consistency between a larger
group of people. But it boils down to trusting each other, and a group
bigger than 20, is a lot of people to get to know.

 I fear the only solution is smaller groups being experts on smaller
 codebases. There is less to review, and more candidates that are likely
 to be experts in this limited area.

 Applied to Nova, that means modularization -- having strong internal
 interfaces and trusting subteams to +2 the code they are experts on.
 Maybe VMWare driver people should just +2 VMware-related code. We've had
 that discussion before, and I know there is a dangerous potential
 quality slope there -- I just fail to see any other solution to bring
 that 750/21=36 figure down to a bearable level, before we burn out all
 of the Nova core team.

This worked really well for Cinder, and I hope Gantt will do the same
kind of thing for Scheduling.

It certainly feels like we really need to split things up, maybe:
* API (talks to compute api to creates tasks and gets objects)
* core task orchestration and persistence (compute api, db objects,
conductor, talks to compute manager api, scheduler api, network api)
* compute manager + drivers (gets instance objects)
* Scheduling (models resources, gets )
* nova-network

But clearly, that will make evolving those interfaces much harder, the
separate they become.

Certainly we fee a few release away from some of those splits.

 I broadly agree - I think that unless Nova moves more towards something
 that is closer to the Linux style subsystem maintainer model we are
 doomed. I know in Linux, the maintainers actually use separate git trees,
 and that isn't what I mean - I think using a single git tree is still
 desirable (at least for now). What I mean is that we should place more
 trust on the opinion of the people who are experts for a particular
 area of code. Let those experts take on a greater burden of the code
 review so core team can put more focus on actual merge approval.

 I know some of the core team try to do this implicitly - eg we know who
 some of the main people involved in hyperv or vmware are, so will tend
 to treat their +1 as an effective +2 from the POV of their driver code,
 but our rules still require two actual +2s from core, so it doesn't
 entirely help us right now. I think we need to do some work in tooling
 to make this more of an explicit process though.

I do prefer a distinction between core and sub-core-team.

Just because we want multiple sub-core-team members, but still make it
easier to spot the core reviewer.

 The problem is that gerrit does not allow us to say person X has +2 for
 code that touches directory path /foo/bar. The +2 is global to the entire
 repository. We could try to deal with this problem outside of gerrit
 though. As a starting point, each virt driver (or major functional area
 of 

Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread Dugger, Donald D
All good points but I want to add an observation.

IRC seems to be the generic answer to all problems and, personally, I don't 
think that's a good medium.  Having to depend upon who just might be on IRC at 
a particular moment seems rather hit or miss.  I much prefer something like 
email where I have a little more time to compose my thoughts, you don't have to 
be right there constantly and there's an easy history.

Note, that's just personal preference, given that IRC is the preferred medium 
for many things I'll just have to change my processes.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com] 
Sent: Friday, August 29, 2014 4:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

Going a bit further up the thread where we are still talking about spec reviews 
and not code reviews...

On 28 August 2014 21:42, Dugger, Donald D donald.d.dug...@intel.com wrote:
 I would contend that that right there is an indication that there's a problem 
 with the process.

We got two nova-core reviewer sponsors, to ensure the code would get reviewed 
before FF.

We probably should have got two nova-driver sponsors for a spec freeze. The 
cores don't have +2 in spec land.

This is the first release we are doing specs, so there are likely to be holes 
in the process. I think next time we could try two nova-cores and two 
nova-drivers (the driver might sign up for the spec review, but not the code 
review).

Also, the spec only got an exception for one week only. I was very late on 
adding the -2, apologies. I just spotted it was missed out, when doing a bit of 
house keeping for juno-3.

 You submit a BP and then you have no idea of what is happening and no way of 
 addressing any issues.  If the priority is wrong I can explain why I think 
 the priority should be higher, getting stonewalled leaves me with no idea 
 what's wrong and no way to address any problems.

Feel free to raise this in the nova-meeting, or ping me or mikal on IRC or via 
email.

 I think, in general, almost everyone is more than willing to adjust proposals 
 based upon feedback.  Tell me what you think is wrong and I'll either explain 
 why the proposal is correct or I'll change it to address the concerns.

Right. In this case, we just didn't get it reviewed. As mentioned, probably 
because people didn't see this as important right now.

 Trying to deal with silence is really hard and really frustrating.  
 Especially given that we're not supposed to spam the mailing it's really hard 
 to know what to do.

For blueprint process stuff, email or catch me (johnthetubaguy) on IRC, or 
mikal on IRC, or any of the nova-drivers. We can usually get you an answer. Or 
generally ask people in #openstack-nova who should be able to point you in the 
right direction.

I don't know the solution but we need to do something.  More core team members 
would help, maybe something like an automatic timeout where BPs/patches with 
no negative scores and no activity for a week get flagged for special handling.

We are brainstorming ideas for Kilo. But its always a balance. I don't want to 
add extra red tape for every issue we have.

Right now we rely on people shouting on IRC if we forget really important 
things, and fixing stuff up as required.

Thanks,
John

___
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] Is the BP approval process broken?

2014-08-29 Thread John Garbutt
On 29 August 2014 18:48, Dugger, Donald D donald.d.dug...@intel.com wrote:
 All good points but I want to add an observation.

 IRC seems to be the generic answer to all problems and, personally, I don't 
 think that's a good medium.  Having to depend upon who just might be on IRC 
 at a particular moment seems rather hit or miss.  I much prefer something 
 like email where I have a little more time to compose my thoughts, you don't 
 have to be right there constantly and there's an easy history.

 Note, that's just personal preference, given that IRC is the preferred medium 
 for many things I'll just have to change my processes.

After moving to use ZNC, I find IRC works much better for me now, but
I am still learning really.

Email is fine. Both works well too (IRC ping me to read the email).

Personally, I find conversations on IRC more efficient than long email
threads, with slow replies. But I certainly want to respect everyones
communication preferences.

John

 -Original Message-
 From: John Garbutt [mailto:j...@johngarbutt.com]
 Sent: Friday, August 29, 2014 4:35 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

 Going a bit further up the thread where we are still talking about spec 
 reviews and not code reviews...

 On 28 August 2014 21:42, Dugger, Donald D donald.d.dug...@intel.com wrote:
 I would contend that that right there is an indication that there's a 
 problem with the process.

 We got two nova-core reviewer sponsors, to ensure the code would get reviewed 
 before FF.

 We probably should have got two nova-driver sponsors for a spec freeze. The 
 cores don't have +2 in spec land.

 This is the first release we are doing specs, so there are likely to be holes 
 in the process. I think next time we could try two nova-cores and two 
 nova-drivers (the driver might sign up for the spec review, but not the code 
 review).

 Also, the spec only got an exception for one week only. I was very late on 
 adding the -2, apologies. I just spotted it was missed out, when doing a bit 
 of house keeping for juno-3.

 You submit a BP and then you have no idea of what is happening and no way of 
 addressing any issues.  If the priority is wrong I can explain why I think 
 the priority should be higher, getting stonewalled leaves me with no idea 
 what's wrong and no way to address any problems.

 Feel free to raise this in the nova-meeting, or ping me or mikal on IRC or 
 via email.

 I think, in general, almost everyone is more than willing to adjust 
 proposals based upon feedback.  Tell me what you think is wrong and I'll 
 either explain why the proposal is correct or I'll change it to address the 
 concerns.

 Right. In this case, we just didn't get it reviewed. As mentioned, probably 
 because people didn't see this as important right now.

 Trying to deal with silence is really hard and really frustrating.  
 Especially given that we're not supposed to spam the mailing it's really 
 hard to know what to do.

 For blueprint process stuff, email or catch me (johnthetubaguy) on IRC, or 
 mikal on IRC, or any of the nova-drivers. We can usually get you an answer. 
 Or generally ask people in #openstack-nova who should be able to point you in 
 the right direction.

I don't know the solution but we need to do something.  More core team 
members would help, maybe something like an automatic timeout where 
BPs/patches with no negative scores and no activity for a week get flagged 
for special handling.

 We are brainstorming ideas for Kilo. But its always a balance. I don't want 
 to add extra red tape for every issue we have.

 Right now we rely on people shouting on IRC if we forget really important 
 things, and fixing stuff up as required.

 Thanks,
 John

 ___
 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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread Sylvain Bauza
lifeSorry folks, I just had a new daughter since Thursday so I'm on 
PTO until Monday, so thanks to the people who discussed about the 
blueprint I created and how we can avoid the problem raised by Don for Kilo.

/life

Answers inline.

Le 29/08/2014 19:42, John Garbutt a écrit :

I think this is now more about code reviews, but this is important...

On 29 August 2014 10:30, Daniel P. Berrange berra...@redhat.com wrote:

On Fri, Aug 29, 2014 at 11:07:33AM +0200, Thierry Carrez wrote:

Joe Gordon wrote:

On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:


 I share Donald's points here, I believe what would help is to
 clearly describe in the Wiki the process and workflow for the BP
 approval process and build in this process how to deal with
 discrepancies/disagreements and build timeframes for each stage and
 process of appeal etc.
 The current process would benefit from some fine tuning and helping
 to build safe guards and time limits/deadlines so folks can expect
 responses within a reasonable time and not be left waiting in the cold.

This is a resource problem, the nova team simply does not have enough
people doing enough reviews to make this possible.

I think Nova lacks core reviewers more than it lacks reviewers, though.
Just looking at the ratio of core developers vs. patchsets proposed,
it's pretty clear that the core team is too small:

Nova: 750 patchsets/month for 21 core = 36
Heat: 230/14 = 16
Swift: 50/16 = 3

Neutron has the same issue (550/14 = 39). I think above 20, you have a
dysfunctional setup. No amount of process, spec, or runway will solve
that fundamental issue.

+1


+1. I can really understand that there is a reviewers bandwidth issue 
within Nova which can't just be answered by adding new cores, because it 
would create some parliament issues.





The problem is, you can't just add core reviewers, they have to actually
understand enough of the code base to be trusted with that +2 power. All
potential candidates are probably already in. In Nova, the code base is
so big it's difficult to find people that know enough of it. In Neutron,
the contributors are often focused on subsections of the code base so
they are not really interested in learning enough of the rest. That
makes the pool of core candidates quite dry.

The other point is keeping the reviews consistent. Making the team
larger makes that harder.

If we did a better job of discussing core disagreements more in the
nova-meeting, maybe that would help keep consistency between a larger
group of people. But it boils down to trusting each other, and a group
bigger than 20, is a lot of people to get to know.


+1 to John, I think adding 5 new cores now would create some problems if 
we do that before discussing how the specs model and the Kilo bps can be 
done. I don't want to do kind of parralelism to what's happening with 
some politics model here but I think we need to have anyway a small 
number of deciders within a big project to make it successful (and 
delegate, but I will explain further below)

I fear the only solution is smaller groups being experts on smaller
codebases. There is less to review, and more candidates that are likely
to be experts in this limited area.

Applied to Nova, that means modularization -- having strong internal
interfaces and trusting subteams to +2 the code they are experts on.
Maybe VMWare driver people should just +2 VMware-related code. We've had
that discussion before, and I know there is a dangerous potential
quality slope there -- I just fail to see any other solution to bring
that 750/21=36 figure down to a bearable level, before we burn out all
of the Nova core team.

This worked really well for Cinder, and I hope Gantt will do the same
kind of thing for Scheduling.

It certainly feels like we really need to split things up, maybe:
* API (talks to compute api to creates tasks and gets objects)
* core task orchestration and persistence (compute api, db objects,
conductor, talks to compute manager api, scheduler api, network api)
* compute manager + drivers (gets instance objects)
* Scheduling (models resources, gets )
* nova-network

But clearly, that will make evolving those interfaces much harder, the
separate they become.

Certainly we fee a few release away from some of those splits.


I broadly agree - I think that unless Nova moves more towards something
that is closer to the Linux style subsystem maintainer model we are
doomed. I know in Linux, the maintainers actually use separate git trees,
and that isn't what I mean - I think using a single git tree is still
desirable (at least for now). What I mean is that we should place more
trust on the opinion of the people who are experts for a particular
area of code. Let those experts take on a greater burden of the code
review so core team can put more focus on actual merge approval.

I know some of the core team try to do this 

Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-29 Thread Joe Gordon
On Aug 29, 2014 10:42 AM, Dugger, Donald D donald.d.dug...@intel.com
wrote:

 Well, I think that there is a sign of a broken (or at least bent) process
and that's what I'm trying to expose.  Especially given the ongoing
conversations over Gantt it seems wrong that ultimately it was rejected due
to silence.  Maybe rejecting the BP was the right decision but the way the
decision was made was just wrong.

 Note that dealing with silence is `really` difficult.  You point out that
maybe silence means people don't agree with the BP but how do I know?
Maybe it means no one has time, maybe no one has an opinion, maybe it got
lost in the shuffle, maybe I'm being too obnoxious - who knows.  A simple
-1 with a one sentence explanation would helped a lot.

How is this:

-1, we already have too many approved blueprints in Juno and it sounds like
there are still concerns about the Gantt split in general. Hopefully after
trunk is open for Kilo we can revisit the Gantt idea. I'm thinking yet
another ML thread outlining why and how to get there.


 --
 Don Dugger
 Censeo Toto nos in Kansa esse decisse. - D. Gale
 Ph: 303/443-3786

 -Original Message-
 From: Jay Pipes [mailto:jaypi...@gmail.com]
 Sent: Friday, August 29, 2014 10:43 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

 On 08/29/2014 12:25 PM, Zane Bitter wrote:
  On 28/08/14 17:02, Jay Pipes wrote:
  I understand your frustration about the silence, but the silence from
  core team members may actually be a loud statement about where their
  priorities are.
 
  I don't know enough about the Nova review situation to say if the
  process is broken or not. But I can say that if passive-aggressively
  ignoring people is considered a primary communication channel,
  something is definitely broken.

 Nobody is ignoring anyone. There have ongoing conversations about the
scheduler and Gantt, and those conversations haven't resulted in all the
decisions that Don would like. That is unfortunate, but it's not a sign of
a broken process.

 -jay


 ___
 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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Daniel P. Berrange
On Thu, Aug 28, 2014 at 01:04:57AM +, Dugger, Donald D wrote:
 I'll try and not whine about my pet project but I do think there
 is a problem here.  For the Gantt project to split out the scheduler
 there is a crucial BP that needs to be implemented (
 https://review.openstack.org/#/c/89893/ ) and, unfortunately, the
 BP has been rejected and we'll have to try again for Kilo.  My question
 is did we do something wrong or is the process broken?
 
 Note that we originally proposed the BP on 4/23/14, went through 10 
 iterations to the final version on 7/25/14 and the final version got
 three +1s and a +2 by 8/5.  Unfortunately, even after reaching out
 to specific people, we didn't get the second +2, hence the rejection.

I see at that it did not even get one +2 at the time of the feature
proposal approval freeze. You then successfully requested an exception
and after a couple more minor updates got a +2 from John but from no
one else.

I do think this shows a flaw in our (core teams) handling of the
blueprint. When we agreed upon the freeze exception, that should
have included a firm commitment for a least 2 core devs to review
it. IOW I think it is reasonable to say that either your feature
should have ended up with two +2s and +A, or you should have seen
a -1 from another core dev. I don't think it is acceptable that
after the exception was approved it only got feedback from one
core dev.   I actually thought that when approving exceptions, we
always got 2 cores to agree to review the item to avoid this, so
I'm not sure why we failed here.

 I understand that reviews are a burden and very hard but it seems
 wrong that a BP with multiple positive reviews and no negative
 reviews is dropped because of what looks like indifference.  Given
 that there is still time to review the actual code patches it seems
 like there should be a simpler way to get a BP approved.  Without
 an approved BP it's difficult to even start the coding process.
 
 I see 2 possibilities here:
 
 
 1)  This is an isolated case specific to this BP.  If so,
 there's no need to change the procedures but I would like to
 know what we should be doing differently.  We got a +2 review 
 on 8/4 and then silence for 3 weeks.
 
 2)  This is a process problem that other people encounter.
 Maybe there are times when silence means assent.  Something
 like a BP with multiple +1s and at least one +2 should
 automatically be accepted if no one reviews it 2 weeks after
 the +2 is given.

My two thoughts are

 - When we approve something for exception should actively monitor
   progress of review to ensure it gets the neccessary attention to
   either approve or reject it. It makes no sense to approve an
   exception and then let it lie silently waiting for weeks with no
   attention. I'd expect that any time exceptions are approved we
   should babysit them and actively review their status in the weekly
   meeting to ensure they are followed up on.

 - Core reviewers should prioritize reviews of things which already
   have a +2 on them. I wrote about this in the context of code reviews
   last week, but all my points apply equally to spec reviews I believe.

http://lists.openstack.org/pipermail/openstack-dev/2014-August/043657.html

Also note that in Kilo the process will be slightly less heavyweight in
that we're going to try allow some features changes into tree without
first requiring a spec/blueprint to be written. I can't say offhand
whether this particular feature would have qualifying for the lighter
process, but in general by reducing need for specs for the more trivial
items, we'll have more time available for review of things which do
require specs.

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] Is the BP approval process broken?

2014-08-28 Thread Joe Gordon
On Thu, Aug 28, 2014 at 2:40 AM, Daniel P. Berrange berra...@redhat.com
wrote:

 On Thu, Aug 28, 2014 at 01:04:57AM +, Dugger, Donald D wrote:
  I'll try and not whine about my pet project but I do think there
  is a problem here.  For the Gantt project to split out the scheduler
  there is a crucial BP that needs to be implemented (
  https://review.openstack.org/#/c/89893/ ) and, unfortunately, the
  BP has been rejected and we'll have to try again for Kilo.  My question
  is did we do something wrong or is the process broken?
 
  Note that we originally proposed the BP on 4/23/14, went through 10
  iterations to the final version on 7/25/14 and the final version got
  three +1s and a +2 by 8/5.  Unfortunately, even after reaching out
  to specific people, we didn't get the second +2, hence the rejection.

 I see at that it did not even get one +2 at the time of the feature
 proposal approval freeze. You then successfully requested an exception
 and after a couple more minor updates got a +2 from John but from no
 one else.

 I do think this shows a flaw in our (core teams) handling of the
 blueprint. When we agreed upon the freeze exception, that should
 have included a firm commitment for a least 2 core devs to review
 it. IOW I think it is reasonable to say that either your feature
 should have ended up with two +2s and +A, or you should have seen
 a -1 from another core dev. I don't think it is acceptable that
 after the exception was approved it only got feedback from one
 core dev.   I actually thought that when approving exceptions, we
 always got 2 cores to agree to review the item to avoid this, so
 I'm not sure why we failed here.

  I understand that reviews are a burden and very hard but it seems
  wrong that a BP with multiple positive reviews and no negative
  reviews is dropped because of what looks like indifference.  Given
  that there is still time to review the actual code patches it seems
  like there should be a simpler way to get a BP approved.  Without
  an approved BP it's difficult to even start the coding process.


So the question is the BP approval process broken doesn't have a simple
answer. There are definitely things we should change, but in this case I
think the process sort of worked. The problem you hit is we just don't have
enough people doing reviews. Your blueprint didn't get approved in part
because the ratio of reviews needed to reviewers is off. If we don't even
have enough bandwidth to approve this spec we certainly don't have enough
bandwidth to review the code associated with the spec.



 
  I see 2 possibilities here:
 
 
  1)  This is an isolated case specific to this BP.  If so,
  there's no need to change the procedures but I would like to
  know what we should be doing differently.  We got a +2 review
  on 8/4 and then silence for 3 weeks.
 
  2)  This is a process problem that other people encounter.
  Maybe there are times when silence means assent.  Something
  like a BP with multiple +1s and at least one +2 should
  automatically be accepted if no one reviews it 2 weeks after
  the +2 is given.

 My two thoughts are

  - When we approve something for exception should actively monitor
progress of review to ensure it gets the neccessary attention to
either approve or reject it. It makes no sense to approve an
exception and then let it lie silently waiting for weeks with no
attention. I'd expect that any time exceptions are approved we
should babysit them and actively review their status in the weekly
meeting to ensure they are followed up on.

  - Core reviewers should prioritize reviews of things which already
have a +2 on them. I wrote about this in the context of code reviews
last week, but all my points apply equally to spec reviews I believe.


 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043657.html

 Also note that in Kilo the process will be slightly less heavyweight in
 that we're going to try allow some features changes into tree without
 first requiring a spec/blueprint to be written. I can't say offhand
 whether this particular feature would have qualifying for the lighter
 process, but in general by reducing need for specs for the more trivial
 items, we'll have more time available for review of things which do
 require specs.


Under the proposed changes to the spec/blueprint process, this would still
need a spec.



 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] Is the BP approval process broken?

2014-08-28 Thread Jay Pipes

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:

I’ll try and not whine about my pet project but I do think there is a
problem here.  For the Gantt project to split out the scheduler there is
a crucial BP that needs to be implemented (
https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP has
been rejected and we’ll have to try again for Kilo.  My question is did
we do something wrong or is the process broken?

Note that we originally proposed the BP on 4/23/14, went through 10
iterations to the final version on 7/25/14 and the final version got
three +1s and a +2 by 8/5.  Unfortunately, even after reaching out to
specific people, we didn’t get the second +2, hence the rejection.

I understand that reviews are a burden and very hard but it seems wrong
that a BP with multiple positive reviews and no negative reviews is
dropped because of what looks like indifference.


I would posit that this is not actually indifference. The reason that 
there may not have been 1 +2 from a core team member may very well have 
been that the core team members did not feel that the blueprint's 
priority was high enough to put before other work, or that the core team 
members did have the time to comment on the spec (due to them not 
feeling the blueprint had the priority to justify the time to do a full 
review).


Note that I'm not a core drivers team member.

Best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Chris Friesen

On 08/28/2014 01:44 PM, Jay Pipes wrote:

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:



I understand that reviews are a burden and very hard but it seems wrong
that a BP with multiple positive reviews and no negative reviews is
dropped because of what looks like indifference.


I would posit that this is not actually indifference. The reason that
there may not have been 1 +2 from a core team member may very well have
been that the core team members did not feel that the blueprint's
priority was high enough to put before other work, or that the core team
members did have the time to comment on the spec (due to them not
feeling the blueprint had the priority to justify the time to do a full
review).


The overall scheduler-lib Blueprint is marked with a high priority 
at http://status.openstack.org/release/;.  Hopefully that would apply 
to sub-blueprints as well.


Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Jay Pipes

On 08/28/2014 04:05 PM, Chris Friesen wrote:

On 08/28/2014 01:44 PM, Jay Pipes wrote:

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:



I understand that reviews are a burden and very hard but it seems wrong
that a BP with multiple positive reviews and no negative reviews is
dropped because of what looks like indifference.


I would posit that this is not actually indifference. The reason that
there may not have been 1 +2 from a core team member may very well have
been that the core team members did not feel that the blueprint's
priority was high enough to put before other work, or that the core team
members did have the time to comment on the spec (due to them not
feeling the blueprint had the priority to justify the time to do a full
review).


The overall scheduler-lib Blueprint is marked with a high priority
at http://status.openstack.org/release/;.  Hopefully that would apply
to sub-blueprints as well.


a) There are no sub-blueprints to that scheduler-lib blueprint

b) If there were sub-blueprints, that does not mean that they would 
necessarily take the same priority as their parent blueprint


c) There's no reason priorities can't be revisited when necessary

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Chris Friesen

On 08/28/2014 02:25 PM, Jay Pipes wrote:

On 08/28/2014 04:05 PM, Chris Friesen wrote:

On 08/28/2014 01:44 PM, Jay Pipes wrote:

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:



I understand that reviews are a burden and very hard but it seems wrong
that a BP with multiple positive reviews and no negative reviews is
dropped because of what looks like indifference.


I would posit that this is not actually indifference. The reason that
there may not have been 1 +2 from a core team member may very well have
been that the core team members did not feel that the blueprint's
priority was high enough to put before other work, or that the core team
members did have the time to comment on the spec (due to them not
feeling the blueprint had the priority to justify the time to do a full
review).


The overall scheduler-lib Blueprint is marked with a high priority
at http://status.openstack.org/release/;.  Hopefully that would apply
to sub-blueprints as well.


a) There are no sub-blueprints to that scheduler-lib blueprint


I guess my terminology was wrong.  The original email referred to 
https://review.openstack.org/#/c/89893/; as the crucial BP that needs 
to be implemented.  That is part of 
https://review.openstack.org/#/q/topic:bp/isolate-scheduler-db,n,z;, 
which is listed as a Gerrit topic in the scheduler-lib blueprint that 
I pointed out.



b) If there were sub-blueprints, that does not mean that they would
necessarily take the same priority as their parent blueprint


I'm not sure how that would work.  If we have a high-priority blueprint 
depending on work that is considered low-priority, that would seem to 
set up a classic priority inversion scenario.



c) There's no reason priorities can't be revisited when necessary


Sure, but in that case it might be a good idea to make the updated 
priority explicit.


Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Jay Pipes


On 08/28/2014 04:42 PM, Dugger, Donald D wrote:

I would contend that that right there is an indication that there's a
problem with the process.  You submit a BP and then you have no idea
of what is happening and no way of addressing any issues.  If the
priority is wrong I can explain why I think the priority should be
higher, getting stonewalled leaves me with no idea what's wrong and
no way to address any problems.

I think, in general, almost everyone is more than willing to adjust
proposals based upon feedback.  Tell me what you think is wrong and
I'll either explain why the proposal is correct or I'll change it to
address the concerns.


In many of the Gantt IRC meetings as well as the ML, I and others have 
repeatedly raised concerns about the scheduler split being premature and 
not a priority compared to the cleanup of the internal interfaces around 
the resource tracker and scheduler. This feedback was echoed in the 
mid-cycle meetup session as well. Sylvain and I have begun the work of 
cleaning up those interfaces and fixing the bugs around non-versioned 
data structures and inconsistent calling interfaces in the scheduler and 
resource tracker. Progress is being made towards these things.



Trying to deal with silence is really hard and really frustrating.
Especially given that we're not supposed to spam the mailing it's
really hard to know what to do.  I don't know the solution but we
need to do something.  More core team members would help, maybe
something like an automatic timeout where BPs/patches with no
negative scores and no activity for a week get flagged for special
handling.


Yes, I think flagging blueprints for special handling would be a good 
thing. Keep in mind, though, that there are an enormous number of 
proposed specifications, with the vast majority of folks only caring 
about their own proposed specs, and very few doing reviews on anything 
other than their own patches or specific area of interest.


Doing reviews on other folks' patches and blueprints would certainly 
help in this regard. If cores only see someone contributing to a small, 
isolated section of the code or only to their own blueprints/patches, 
they generally tend to implicitly down-play that person's reviews in 
favor of patches/blueprints from folks that are reviewing non-related 
patches and contributing to reduce the total review load.


I understand your frustration about the silence, but the silence from 
core team members may actually be a loud statement about where their 
priorities are.


Best,
-jay


I feel we need to change the process somehow.

-- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph:
303/443-3786

-Original Message- From: Jay Pipes
[mailto:jaypi...@gmail.com] Sent: Thursday, August 28, 2014 1:44 PM
To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
[nova] Is the BP approval process broken?

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:

I'll try and not whine about my pet project but I do think there is
a problem here.  For the Gantt project to split out the scheduler
there is a crucial BP that needs to be implemented (
https://review.openstack.org/#/c/89893/ ) and, unfortunately, the
BP has been rejected and we'll have to try again for Kilo.  My
question is did we do something wrong or is the process broken?

Note that we originally proposed the BP on 4/23/14, went through
10 iterations to the final version on 7/25/14 and the final version
got three +1s and a +2 by 8/5.  Unfortunately, even after reaching
out to specific people, we didn't get the second +2, hence the
rejection.

I understand that reviews are a burden and very hard but it seems
wrong that a BP with multiple positive reviews and no negative
reviews is dropped because of what looks like indifference.


I would posit that this is not actually indifference. The reason that
there may not have been 1 +2 from a core team member may very well
have been that the core team members did not feel that the
blueprint's priority was high enough to put before other work, or
that the core team members did have the time to comment on the spec
(due to them not feeling the blueprint had the priority to justify
the time to do a full review).

Note that I'm not a core drivers team member.

Best, -jay


___ 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




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Chris Friesen

On 08/28/2014 03:02 PM, Jay Pipes wrote:


I understand your frustration about the silence, but the silence from
core team members may actually be a loud statement about where their
priorities are.


Or it could be that they haven't looked at it, aren't aware of it, or 
haven't been paying attention.


I think it would be better to make feedback explicit and remove any 
uncertainty/ambiguity.


Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
+1, that would be the most pragmatic way to address this, silence has different 
meanings to different people, a response would clarify the ambiguity and 
misunderstanding.
/Alan

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com] 
Sent: August-28-14 11:18 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/28/2014 03:02 PM, Jay Pipes wrote:

 I understand your frustration about the silence, but the silence from 
 core team members may actually be a loud statement about where their 
 priorities are.

Or it could be that they haven't looked at it, aren't aware of it, or haven't 
been paying attention.

I think it would be better to make feedback explicit and remove any 
uncertainty/ambiguity.

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] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
I don't think silence ever helps, its better to respond even if it is to 
disagree, one on one with the person.
Alan

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: August-28-14 11:02 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?


On 08/28/2014 04:42 PM, Dugger, Donald D wrote:
 I would contend that that right there is an indication that there's a 
 problem with the process.  You submit a BP and then you have no idea 
 of what is happening and no way of addressing any issues.  If the 
 priority is wrong I can explain why I think the priority should be 
 higher, getting stonewalled leaves me with no idea what's wrong and no 
 way to address any problems.

 I think, in general, almost everyone is more than willing to adjust 
 proposals based upon feedback.  Tell me what you think is wrong and 
 I'll either explain why the proposal is correct or I'll change it to 
 address the concerns.

In many of the Gantt IRC meetings as well as the ML, I and others have 
repeatedly raised concerns about the scheduler split being premature and not a 
priority compared to the cleanup of the internal interfaces around the resource 
tracker and scheduler. This feedback was echoed in the mid-cycle meetup session 
as well. Sylvain and I have begun the work of cleaning up those interfaces and 
fixing the bugs around non-versioned data structures and inconsistent calling 
interfaces in the scheduler and resource tracker. Progress is being made 
towards these things.

 Trying to deal with silence is really hard and really frustrating.
 Especially given that we're not supposed to spam the mailing it's 
 really hard to know what to do.  I don't know the solution but we need 
 to do something.  More core team members would help, maybe something 
 like an automatic timeout where BPs/patches with no negative scores 
 and no activity for a week get flagged for special handling.

Yes, I think flagging blueprints for special handling would be a good thing. 
Keep in mind, though, that there are an enormous number of proposed 
specifications, with the vast majority of folks only caring about their own 
proposed specs, and very few doing reviews on anything other than their own 
patches or specific area of interest.

Doing reviews on other folks' patches and blueprints would certainly help in 
this regard. If cores only see someone contributing to a small, isolated 
section of the code or only to their own blueprints/patches, they generally 
tend to implicitly down-play that person's reviews in favor of 
patches/blueprints from folks that are reviewing non-related patches and 
contributing to reduce the total review load.

I understand your frustration about the silence, but the silence from core team 
members may actually be a loud statement about where their priorities are.

Best,
-jay

 I feel we need to change the process somehow.

 -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph:
 303/443-3786

 -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] 
 Sent: Thursday, August 28, 2014 1:44 PM
 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] 
 [nova] Is the BP approval process broken?

 On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
 I'll try and not whine about my pet project but I do think there is a 
 problem here.  For the Gantt project to split out the scheduler there 
 is a crucial BP that needs to be implemented ( 
 https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP 
 has been rejected and we'll have to try again for Kilo.  My question 
 is did we do something wrong or is the process broken?

 Note that we originally proposed the BP on 4/23/14, went through
 10 iterations to the final version on 7/25/14 and the final version 
 got three +1s and a +2 by 8/5.  Unfortunately, even after reaching 
 out to specific people, we didn't get the second +2, hence the 
 rejection.

 I understand that reviews are a burden and very hard but it seems 
 wrong that a BP with multiple positive reviews and no negative 
 reviews is dropped because of what looks like indifference.

 I would posit that this is not actually indifference. The reason that 
 there may not have been 1 +2 from a core team member may very well 
 have been that the core team members did not feel that the blueprint's 
 priority was high enough to put before other work, or that the core 
 team members did have the time to comment on the spec (due to them not 
 feeling the blueprint had the priority to justify the time to do a 
 full review).

 Note that I'm not a core drivers team member.

 Best, -jay


 ___ 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

Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
I share Donald's points here, I believe what would help is to clearly describe 
in the Wiki the process and workflow for the BP approval process and build in 
this process how to deal with discrepancies/disagreements and build timeframes 
for each stage and process of appeal etc.
The current process would benefit from some fine tuning and helping to build 
safe guards and time limits/deadlines so folks can expect responses within a 
reasonable time and not be left waiting in the cold. 
My 2cents!
/Alan

-Original Message-
From: Dugger, Donald D [mailto:donald.d.dug...@intel.com] 
Sent: August-28-14 10:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

I would contend that that right there is an indication that there's a problem 
with the process.  You submit a BP and then you have no idea of what is 
happening and no way of addressing any issues.  If the priority is wrong I can 
explain why I think the priority should be higher, getting stonewalled leaves 
me with no idea what's wrong and no way to address any problems.

I think, in general, almost everyone is more than willing to adjust proposals 
based upon feedback.  Tell me what you think is wrong and I'll either explain 
why the proposal is correct or I'll change it to address the concerns.

Trying to deal with silence is really hard and really frustrating.  Especially 
given that we're not supposed to spam the mailing it's really hard to know what 
to do.  I don't know the solution but we need to do something.  More core team 
members would help, maybe something like an automatic timeout where BPs/patches 
with no negative scores and no activity for a week get flagged for special 
handling.

I feel we need to change the process somehow.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Thursday, August 28, 2014 1:44 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
 I'll try and not whine about my pet project but I do think there is a 
 problem here.  For the Gantt project to split out the scheduler there 
 is a crucial BP that needs to be implemented ( 
 https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP 
 has been rejected and we'll have to try again for Kilo.  My question 
 is did we do something wrong or is the process broken?

 Note that we originally proposed the BP on 4/23/14, went through 10 
 iterations to the final version on 7/25/14 and the final version got 
 three +1s and a +2 by 8/5.  Unfortunately, even after reaching out to 
 specific people, we didn't get the second +2, hence the rejection.

 I understand that reviews are a burden and very hard but it seems 
 wrong that a BP with multiple positive reviews and no negative reviews 
 is dropped because of what looks like indifference.

I would posit that this is not actually indifference. The reason that there may 
not have been 1 +2 from a core team member may very well have been that the 
core team members did not feel that the blueprint's priority was high enough to 
put before other work, or that the core team members did have the time to 
comment on the spec (due to them not feeling the blueprint had the priority to 
justify the time to do a full review).

Note that I'm not a core drivers team member.

Best,
-jay


___
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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Joe Gordon
On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh alan.kavan...@ericsson.com
wrote:

 I share Donald's points here, I believe what would help is to clearly
 describe in the Wiki the process and workflow for the BP approval process
 and build in this process how to deal with discrepancies/disagreements and
 build timeframes for each stage and process of appeal etc.
 The current process would benefit from some fine tuning and helping to
 build safe guards and time limits/deadlines so folks can expect responses
 within a reasonable time and not be left waiting in the cold.



This is a resource problem, the nova team simply does not have enough
people doing enough reviews to make this possible.


 My 2cents!
 /Alan

 -Original Message-
 From: Dugger, Donald D [mailto:donald.d.dug...@intel.com]
 Sent: August-28-14 10:43 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

 I would contend that that right there is an indication that there's a
 problem with the process.  You submit a BP and then you have no idea of
 what is happening and no way of addressing any issues.  If the priority is
 wrong I can explain why I think the priority should be higher, getting
 stonewalled leaves me with no idea what's wrong and no way to address any
 problems.

 I think, in general, almost everyone is more than willing to adjust
 proposals based upon feedback.  Tell me what you think is wrong and I'll
 either explain why the proposal is correct or I'll change it to address the
 concerns.

 Trying to deal with silence is really hard and really frustrating.
 Especially given that we're not supposed to spam the mailing it's really
 hard to know what to do.  I don't know the solution but we need to do
 something.  More core team members would help, maybe something like an
 automatic timeout where BPs/patches with no negative scores and no activity
 for a week get flagged for special handling.

 I feel we need to change the process somehow.

 --
 Don Dugger
 Censeo Toto nos in Kansa esse decisse. - D. Gale
 Ph: 303/443-3786

 -Original Message-
 From: Jay Pipes [mailto:jaypi...@gmail.com]
 Sent: Thursday, August 28, 2014 1:44 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

 On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
  I'll try and not whine about my pet project but I do think there is a
  problem here.  For the Gantt project to split out the scheduler there
  is a crucial BP that needs to be implemented (
  https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP
  has been rejected and we'll have to try again for Kilo.  My question
  is did we do something wrong or is the process broken?
 
  Note that we originally proposed the BP on 4/23/14, went through 10
  iterations to the final version on 7/25/14 and the final version got
  three +1s and a +2 by 8/5.  Unfortunately, even after reaching out to
  specific people, we didn't get the second +2, hence the rejection.
 
  I understand that reviews are a burden and very hard but it seems
  wrong that a BP with multiple positive reviews and no negative reviews
  is dropped because of what looks like indifference.

 I would posit that this is not actually indifference. The reason that
 there may not have been 1 +2 from a core team member may very well have
 been that the core team members did not feel that the blueprint's priority
 was high enough to put before other work, or that the core team members did
 have the time to comment on the spec (due to them not feeling the blueprint
 had the priority to justify the time to do a full review).

 Note that I'm not a core drivers team member.

 Best,
 -jay


 ___
 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

 ___
 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] Is the BP approval process broken?

2014-08-28 Thread Boris Pavlovic
Joe,


This is a resource problem, the nova team simply does not have enough
 people doing enough reviews to make this possible.


Adding in such case more bureaucracy (specs) is not the best way to resolve
team throughput issues...

my 2cents


Best regards,
Boris Pavlovic


On Fri, Aug 29, 2014 at 2:01 AM, Joe Gordon joe.gord...@gmail.com wrote:




 On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh alan.kavan...@ericsson.com
  wrote:

 I share Donald's points here, I believe what would help is to clearly
 describe in the Wiki the process and workflow for the BP approval process
 and build in this process how to deal with discrepancies/disagreements and
 build timeframes for each stage and process of appeal etc.
 The current process would benefit from some fine tuning and helping to
 build safe guards and time limits/deadlines so folks can expect responses
 within a reasonable time and not be left waiting in the cold.



 This is a resource problem, the nova team simply does not have enough
 people doing enough reviews to make this possible.


 My 2cents!
 /Alan

 -Original Message-
 From: Dugger, Donald D [mailto:donald.d.dug...@intel.com]
 Sent: August-28-14 10:43 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

 I would contend that that right there is an indication that there's a
 problem with the process.  You submit a BP and then you have no idea of
 what is happening and no way of addressing any issues.  If the priority is
 wrong I can explain why I think the priority should be higher, getting
 stonewalled leaves me with no idea what's wrong and no way to address any
 problems.

 I think, in general, almost everyone is more than willing to adjust
 proposals based upon feedback.  Tell me what you think is wrong and I'll
 either explain why the proposal is correct or I'll change it to address the
 concerns.

 Trying to deal with silence is really hard and really frustrating.
 Especially given that we're not supposed to spam the mailing it's really
 hard to know what to do.  I don't know the solution but we need to do
 something.  More core team members would help, maybe something like an
 automatic timeout where BPs/patches with no negative scores and no activity
 for a week get flagged for special handling.

 I feel we need to change the process somehow.

 --
 Don Dugger
 Censeo Toto nos in Kansa esse decisse. - D. Gale
 Ph: 303/443-3786

 -Original Message-
 From: Jay Pipes [mailto:jaypi...@gmail.com]
 Sent: Thursday, August 28, 2014 1:44 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

 On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
  I'll try and not whine about my pet project but I do think there is a
  problem here.  For the Gantt project to split out the scheduler there
  is a crucial BP that needs to be implemented (
  https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP
  has been rejected and we'll have to try again for Kilo.  My question
  is did we do something wrong or is the process broken?
 
  Note that we originally proposed the BP on 4/23/14, went through 10
  iterations to the final version on 7/25/14 and the final version got
  three +1s and a +2 by 8/5.  Unfortunately, even after reaching out to
  specific people, we didn't get the second +2, hence the rejection.
 
  I understand that reviews are a burden and very hard but it seems
  wrong that a BP with multiple positive reviews and no negative reviews
  is dropped because of what looks like indifference.

 I would posit that this is not actually indifference. The reason that
 there may not have been 1 +2 from a core team member may very well have
 been that the core team members did not feel that the blueprint's priority
 was high enough to put before other work, or that the core team members did
 have the time to comment on the spec (due to them not feeling the blueprint
 had the priority to justify the time to do a full review).

 Note that I'm not a core drivers team member.

 Best,
 -jay


 ___
 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

 ___
 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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi

Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Chris Friesen

On 08/28/2014 04:01 PM, Joe Gordon wrote:




On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:

I share Donald's points here, I believe what would help is to
clearly describe in the Wiki the process and workflow for the BP
approval process and build in this process how to deal with
discrepancies/disagreements and build timeframes for each stage and
process of appeal etc.
The current process would benefit from some fine tuning and helping
to build safe guards and time limits/deadlines so folks can expect
responses within a reasonable time and not be left waiting in the cold.


This is a resource problem, the nova team simply does not have enough
people doing enough reviews to make this possible.


All the more reason to make it obvious which reviews are not being 
addressed in a timely fashion.  (I'm thinking something akin to the 
order screen at a fast food restaurant that starts blinking in red and 
beeping if an order hasn't been filled in a certain amount of time.)


Perhaps by making it clear that reviews are a bottleneck this will 
actually help to address the problem.


Chris


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
+1 my sentiments exactly, and this will actually help folks contribute in a 
more meaningful and productive way.
/Alan

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com] 
Sent: August-29-14 12:28 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/28/2014 04:01 PM, Joe Gordon wrote:



 On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh 
 alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:

 I share Donald's points here, I believe what would help is to
 clearly describe in the Wiki the process and workflow for the BP
 approval process and build in this process how to deal with
 discrepancies/disagreements and build timeframes for each stage and
 process of appeal etc.
 The current process would benefit from some fine tuning and helping
 to build safe guards and time limits/deadlines so folks can expect
 responses within a reasonable time and not be left waiting in the cold.


 This is a resource problem, the nova team simply does not have enough 
 people doing enough reviews to make this possible.

All the more reason to make it obvious which reviews are not being addressed in 
a timely fashion.  (I'm thinking something akin to the order screen at a fast 
food restaurant that starts blinking in red and beeping if an order hasn't been 
filled in a certain amount of time.)

Perhaps by making it clear that reviews are a bottleneck this will actually 
help to address the problem.

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] Is the BP approval process broken?

2014-08-28 Thread Joe Gordon
On Thu, Aug 28, 2014 at 3:27 PM, Chris Friesen chris.frie...@windriver.com
wrote:

 On 08/28/2014 04:01 PM, Joe Gordon wrote:




 On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
 alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:

 I share Donald's points here, I believe what would help is to
 clearly describe in the Wiki the process and workflow for the BP
 approval process and build in this process how to deal with
 discrepancies/disagreements and build timeframes for each stage and
 process of appeal etc.
 The current process would benefit from some fine tuning and helping
 to build safe guards and time limits/deadlines so folks can expect
 responses within a reasonable time and not be left waiting in the
 cold.


 This is a resource problem, the nova team simply does not have enough
 people doing enough reviews to make this possible.


 All the more reason to make it obvious which reviews are not being
 addressed in a timely fashion.  (I'm thinking something akin to the order
 screen at a fast food restaurant that starts blinking in red and beeping if
 an order hasn't been filled in a certain amount of time.)

 Perhaps by making it clear that reviews are a bottleneck this will
 actually help to address the problem.


Yes, better tracking of when a review goes stale (nova and nova-specs) is a
great idea. Now we just need a volunteer to work on a good way to identify
them, make that information easy to consume, and make a plan to help us
wrangle the reviews.

Russell has some numbers (and code) around this, Nova has 618 open reviews,
of which 225 are waiting for reviewers [0].

[0] http://russellbryant.net/openstack-stats/nova-openreviews.html




 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


[openstack-dev] [nova] Is the BP approval process broken?

2014-08-27 Thread Dugger, Donald D
I'll try and not whine about my pet project but I do think there is a problem 
here.  For the Gantt project to split out the scheduler there is a crucial BP 
that needs to be implemented ( https://review.openstack.org/#/c/89893/ ) and, 
unfortunately, the BP has been rejected and we'll have to try again for Kilo.  
My question is did we do something wrong or is the process broken?

Note that we originally proposed the BP on 4/23/14, went through 10 iterations 
to the final version on 7/25/14 and the final version got three +1s and a +2 by 
8/5.  Unfortunately, even after reaching out to specific people, we didn't get 
the second +2, hence the rejection.

I understand that reviews are a burden and very hard but it seems wrong that a 
BP with multiple positive reviews and no negative reviews is dropped because of 
what looks like indifference.  Given that there is still time to review the 
actual code patches it seems like there should be a simpler way to get a BP 
approved.  Without an approved BP it's difficult to even start the coding 
process.

I see 2 possibilities here:


1)  This is an isolated case specific to this BP.  If so, there's no need 
to change the procedures but I would like to know what we should be doing 
differently.  We got a +2 review on 8/4 and then silence for 3 weeks.

2)  This is a process problem that other people encounter.  Maybe there are 
times when silence means assent.  Something like a BP with multiple +1s and at 
least one +2 should automatically be accepted if no one reviews it 2 weeks 
after the +2 is given.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev