[openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers
Matthew Booth
mbooth at redhat.com
Tue Sep 9 11:05:47 UTC 2014
On 09/09/14 01:20, Stefano Maffulli wrote:
> From conversations with PTLs and core reviewers I get the impression
> that lots of drivers contributions come with bad code. These require a
> lot of time and reviewers energy to be cleaned up, causing burn out and
> bad feelings on all sides. What if we establish a new 'place' of some
> sort where we can send people to improve their code (or dump it without
> interfering with core?) Somewhere there may be a workflow
> "go-improve-over-there" where a Community Manager (or mentors or some
> other program we may invent) takes over and does what core reviewers
> have been trying to do 'on the side'? The advantage is that this way we
> don't have to change radically how current teams operate, we may be able
> to start this immediately with Kilo. Thoughts?
I can't speak for other areas of the codebase, but certainly in the
VMware driver the technical debt has been allowed to accrue in the past
precisely because the review process itself is so tortuously slow. This
results in a death spiral of code quality, and ironically the review
process has been the cause, not the solution.
In Juno we have put our major focus on refactor work, which has meant
essentially no feature work for an entire cycle. This is painful, but
unfortunately necessary with the current process.
As an exercise, look at what has been merged in the VMware driver during
Juno. Consider how many developer weeks that should reasonably have
taken. Then consider how many developer weeks it actually took. Is the
current process conducive to productivity? The answer is clearly and
emphatically no. Is it worth it in its current form? Obviously not.
So, should driver contributors be forced to play in the sandpit before
mixing with the big boys? If a tortuously slow review process is a
primary cause of technical debt, will adding more steps to it improve
the situation? I hope the answer is obvious. And I'll be honest, I found
the suggestion more than a little patronising.
Matt
--
Matthew Booth
Red Hat Engineering, Virtualisation Team
Phone: +442070094448 (UK)
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
More information about the OpenStack-dev
mailing list