Thanks for the deck Jay, that is very helpful. Also, would it help the process by having some clear guidelines/expectations around review time as well? In particular, if you have put a -1 or -2, and the issues that you have identified have been addressed by an update (or at least the original author thinks that he has addressed your concern), is it reasonable to expect that you will re-review in a "reasonable time"? This way, the updates can either proceed, or be rejected, as they are being developed instead of accumulating in a backlog that we then try to get approved on the last day of the cut-off?
Regards, Mandeep On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon <sgor...@redhat.com> wrote: > ----- Original Message ----- > > From: "Jay Pipes" <jaypi...@gmail.com> > > To: firstname.lastname@example.org > > > > On 07/24/2014 10:05 AM, CARVER, PAUL wrote: > > > Alan Kavanagh wrote: > > > > > >> If we have more work being put on the table, then more Core > > >> members would definitely go a long way with assisting this, we cant > > >> wait for folks to be reviewing stuff as an excuse to not get > > >> features landed in a given release. > > > > We absolutely can and should wait for folks to be reviewing stuff > > properly. A large number of problems in OpenStack code and flawed design > > can be attributed to impatience and pushing through code that wasn't > ready. > > > > I've said this many times, but the best way to get core reviews on > > patches that you submit is to put the effort into reviewing others' > > code. Core reviewers are more willing to do reviews for someone who is > > clearly trying to help the project in more ways than just pushing their > > own code. Note that, Alan, I'm not trying to imply that you are guilty > > of the above! :) I'm just recommending techniques for the general > > contributor community who are not on a core team (including myself!). > > I agree with all of the above, I do think however there is another > un-addressed area where there *may* be room for optimization - which is how > we use the earlier milestones. I apologize in advance because this is > somewhat tangential to Alan's points but I think it is relevant to the > general frustration around what did/didn't get approved in time for the > deadline and ultimately what will or wont get reviewed in time to make the > release versus being punted to Kilo or even further down the road. > > We land very, very, little in terms of feature work in the *-1 and *-2 > milestones in each release (and this is not just a Neutron thing). Even > though we know without a doubt that the amount of work currently approved > for J-3 is not realistic we also know that we will land significantly more > features in this milestone than the other two that have already been and > gone, which to my way of thinking is actually kind of backwards to the > ideal situation. > > What is unclear to me however is how much of this is a result of > difficulty identifying and approving less controversial/more > straightforward specifications quickly following summit (keeping in mind > this time around there was arguably some additional delay as the *-specs > repository approach was bedded down), an unavoidable result of human nature > being to *really* push when there is a *hard* deadline to beat, or just > that these earlier milestones are somewhat impacted from fatigue from the > summit (I know a lot of people also try to take some well earned time off > around this period + of course many are still concentrated on stabilization > of the previous release). As a result it's unclear whether there is > anything concrete that can be done to change this but I thought I would > bring it up in case anyone else has any bright ideas! > > > [SNIP] > > > > We ought to (in my personal opinion) be supplying core reviewers to > > > at least a couple of OpenStack projects. But one way or another we > > > need to get more capabilities reviewed and merged. My personal top > > > disappointments are with the current state of IPv6, HA, and QoS, but > > > I'm sure other folks can list lots of other capabilities that > > > they're really going to be frustrated to find lacking in Juno. > > > > I agree with you. It's not something that is fixable overnight, or by a > > small group of people, IMO. It's something that needs to be addressed by > > the core project teams, acting as a group in order to reduce review wait > > times and ensure that there is responsiveness, transparency and > > thoroughness to the review (code as well as spec) process. > > > > I put together some slides recently that have some insights and > > (hopefully) some helpful suggestions for both doing and receiving code > > reviews, as well as staying sane in the era of corporate agendas. > > Perhaps folks will find it useful: > > > > http://bit.ly/navigating-openstack-community > > As an aside this is a very well put together deck, thanks for sharing! > > -Steve > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev