Open Stack

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!).

> Stability is absolutely essential so we can't force things through
> without adequate review. The automated CI testing in OpenStack is
> impressive, but it is far from flawless and even if it worked
> perfectly it's still just CI, not AI. There's a large class of
> problems that it just can't catch.

Yes, exactly.

> I agree with Alan that if there's a discrepancy between the amount
> of code that folks would like to land in a release and the number of
> core member working hours in a six month period then that is
> something the board needs to take an interest in.

Well, technically this is not at all what the OpenStack board is
responsible for. This is likely the purview of the PTLs, the individual
project core teams, and possibly the Technical Committee. The board is
really about company-to-company interests, legal and product marketing
topics, and such.

> I think a friendly adversarial approach is healthy for OpenStack.
> Specs and code should need to be defended, not just rubber stamped.

++

> Having core reviewers critiquing code written by their competitors,
> suppliers, or vendors is healthy for the overall code quality.

++

> However, simply having specs and code not get reviewed at all due to
> a shortage of core reviewers is not healthy and will limit the
> success of OpenStack.

Agreed.

> I don't really follow Linux kernel development, but a quick search
> turned up [1] which seems to indicate at least one additional level
> between developer and core (depending on whether we consider Linus
> and Andrew levels unto themselves and whether we consider OpenStack
> projects as full systems or as subsystems of OpenStack.
>
> Speaking only for myself and not AT&T, I'm disappointed that my
> employer doesn't have more developers actively writing code.

As an ex-AT&T-er, I would agree with that sentiment.

> 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

Best,
-jay

> [1]
> http://techblog.aasisvinayak.com/linux-kernel-development-process-how-it-works/
>
>
>
>
>
> _______________________________________________ OpenStack-dev
> mailing list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>