Open Stack

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.

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.

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.

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.

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

[1] http://techblog.aasisvinayak.com/linux-kernel-development-process-how-it-works/