On Fri, Jul 25, 2014 at 2:50 PM, Steve Gordon <[email protected]> wrote: > ----- Original Message ----- >> From: "Jay Pipes" <[email protected]> >> To: [email protected] >> >> 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. > This is how it always is, yes.
> 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! > I think it's a little bit of human nature, and a little bit of stalling. The final milestone for a release is the *final* milestone for that release. So, a rush is always going to happen. I also think that I find cores focus on reviews easier near the end. I've tried experimenting with review assignments near the end of Juno-2 (didn't work out well), and I'm going to try it again in Juno-3 to see if it works better there. The bottom line is that I agree with you, and I'm open to ideas in how to solve the "final milestone" issue. Thanks, Kyle >> [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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
