Open Stack

On Thu, Aug 7, 2014 at 7:33 AM, Anne Gentle <anne at openstack.org> wrote:

>
>
>
> On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant <rbryant at redhat.com> wrote:
>
>> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is
>> slot selection would just be Nova drivers. I
>> > think there is an assumption in the old system that everyone in Nova
>> > core wants to prioritize the blueprints. I think there are a bunch of
>> > folks in Nova core that are happy having signaling from Nova drivers on
>> > high priority things to review. (I know I'm in that camp.)
>> >
>> > Lacking that we all have picking algorithms to hack away at the 500 open
>> > reviews. Which basically means it's a giant random queue.
>> >
>> > Having a few blueprints that *everyone* is looking at also has the
>> > advantage that the context for the bits in question will tend to be
>> > loaded into multiple people's heads at the same time, so is something
>> > that's discussable.
>> >
>> > Will it fix the issue, not sure, but it's an idea.
>>
>> OK, got it.  So, success critically depends on nova-core being willing
>> to take review direction and priority setting from nova-drivers.  That
>> sort of assumption is part of why I think agile processes typically
>> don't work in open source.  We don't have the ability to direct people
>> with consistent and reliable results.
>>
>> I'm afraid if people doing the review are not directly involved in at
>> least ACKing the selection and commiting to review something, putting
>> stuff in slots seems futile.
>>
>>
> My original thinking was I'd set aside a "meeting time" to review specs
> especially for doc issues and API designs. What I found quickly was that
> the 400+ queue in one project alone was not only daunting but felt like I
> wasn't going to make a dent as a single person, try as I may.
>
> I did my best but would appreciate any change in process to help with
> prioritization. I'm pretty sure it will help someone like me, looking at
> cross-project queues of specs, to know what to review first, second, third,
> and what to circle back on.
>
>
>> --
>> Russell Bryant
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ​Seems everybody that's been around a while has noticed "issues" this
release and have talked about it, thanks Thierry for putting it together so
well and kicking off the ML thread here.

I'd agree with everything that you stated, I've also floated the idea this
past week with a few members of the Core Cinder team to have an "every
other" release for new drivers submissions in Cinder (I'm expecting this to
be a HUGELY popular proposal [note sarcastic tone]).

There are three things that have just crushed productivity and motivation
in Cinder this release (IMO):
1. Overwhelming number of drivers (tactical contributions)
2. Overwhelming amount of churn, literally hundreds of little changes to
modify docstrings, comments etc but no real improvements to code
3. A new sense of pride in hitting the -1 button on reviews.  A large
number of reviews these days seem to be -1 due to punctuation or
misspelling in comments and docstrings.  There's also a lot of "my way of
writing this method is better because it's *clever*" taking place.

In Cinder's case I don't think new features is a problem, in fact we can't
seem to get new features worked on and released because of all the other
distractions.  That being said doing a maintenance or hardening only type
of release is for sure good with me.

Anyway, I've had some plans to talk about how we might fix some of this in
Cinder at next week's sprint.  If there's a broader community effort along
these lines that's even better.

Thanks,
John
    ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140807/2e52c837/attachment.html>