Re: [openstack-dev] [nova] Is the BP approval process broken?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
+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?
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?
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?
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?
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?
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?
+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?
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?
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
