Open Stack

On Fri, Jul 25, 2014 at 2:50 PM, Steve Gordon <sgordon at redhat.com> wrote:
> ----- Original Message -----
>> From: "Jay Pipes" <jaypipes at gmail.com>
>> To: openstack-dev at lists.openstack.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.
>
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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev