Open Stack

On Fri, Apr 3, 2015 at 12:38 AM, Matthew Booth <mbooth at redhat.com> wrote:
> On 02/04/15 07:20, Michael Still wrote:

First off, sorry for the slow reply to this email. The reason that I
sent my candidacy email at the very start of the election window is
that Easter is a four day holiday in Australia, so I sent the email
about then disappeared to do family stuff all weekend. I'm only just
catching up on email now.

>> I'd like another term as Nova PTL, if you'll have me.

[snip]

>> I think its a good idea also to examine briefly some statistics about specs:
>>
>> Juno:
>>    approved but not implemented: 40
>>    implemented: 49
>>
>> Kilo:
>>    approved but not implemented: 30
>>    implemented: 32

[snip]

> It has been my impression over at least the last 2 releases that the
> most significant barrier to progress in Nova is the lack of core
> reviewer bandwidth. This affects not only feature development, but also
> the much less sexy paying down of technical debt. There have been
> various attempts to redefine roles and create new processes, but no
> attempt that I have seen to address the underlying fundamental issue:
> the lack of people who can +2 patches.
>
> There is a discussion currently ongoing on this list, "The Evolution of
> core developer to maintainer", which contains a variety of proposals.
> However, none of these will gain anything close to a consensus. The
> result of this will be that none of them will be implemented. We will be
> left by default with the status quo, and the situation will continue not
> to improve despite the new processes we will invent instead.
>
> The only way we are going to change the status quo is by fiat. We should
> of course make every effort to get as many people on board as possible.
> However, when change is required, but nobody can agree precisely which
> change, we need positive leadership from the PTL.
>
> Would you like to take a position on how to improve core reviewer
> throughput in the next cycle?

Thanks for the question.

I agree that cores aren't keeping up with the workload in Nova,
although I think its a quite complicated issue with no single fix.

For example, we could look at the number of patchsets, and the number
of reviews by cores and decide that cores aren't keeping up. That
doesn't take into account the number of those patchsets waiting on the
author to respond to comments from a previous reviewer though. It also
doesn't take into account that patchsets at the end of review chains
will by definition take a longer time to merge and therefore will
experience more patchsets through rebases. As a tangible example, when
the VMWare driver was being refactored there were patches at the end
of the review chain which ended up with 40 or 50 revisions through
this rebasing. That's not actually a problem as long as the _start_ of
the review chain is getting active reviews.

Additionally, we have consistently asked for non-cores to help cover
the review load. It doesn't have to be a core that notices a problem
with a patch -- anyone can do that. There are many people who do help
out with non-core reviews, and I am thankful for all of them. However,
I keep meeting people who complain about review delays, but who don't
have a history of reviewing themselves. That's confusing and
frustrating to me.

So, we need to encourage everyone to do more reviews, not just promote
more cores to rubber stamp. We also need to work on better metrics for
which reviews are genuinely blocked (i.e. not waiting on the author to
perform an action or stuck at the end of a review chain). Russell has
done some work on this in the past, but its something that I think
needs a reinvigorated effort in Liberty.

That said, you're right. Core is too static a group. There are still
cores not doing many reviews, and the group should grow as Nova grows.
Last release I asked cores to keep an eye out for people who were
close to being trusted enough, so that we could mentor those people
across the line. That work needs to continue in Liberty.

With our current veto process for core nominations, it is very easy
for a proposed core to be blocked from being added. I think our
"founding developers" had good intent here -- core disagreements are
expensive to resolve and slow us down even more than blocking on
reviews. We do need to grow more cores though as the current ones drop
away through attrition.

I don't have a simple solution to this problem. I do think its
something we can solve if we keep hammering at it though.

Michael

-- 
Rackspace Australia