On Fri, Apr 3, 2015 at 12:38 AM, Matthew Booth <mbo...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev