Open Stack

On Mon, 2014-09-08 at 17:20 -0700, Stefano Maffulli wrote:
> On 09/05/2014 07:07 PM, James Bottomley wrote:
> > Actually, I don't think this analysis is accurate.  Some people are
> > simply interested in small aspects of a project.  It's the "scratch your
> > own itch" part of open source.  The thing which makes itch scratchers
> > not lone wolfs is the desire to go the extra mile to make what they've
> > done useful to the community.  If they never do this, they likely have a
> > forked repo with only their changes (and are the epitome of a lone
> > wolf).  If you scratch your own itch and make the effort to get it
> > upstream, you're assisting the community (even if that's the only piece
> > of code you do) and that assistance makes you (at least for a time) part
> > of the community.
> 
> I'm starting to think that the processes we have implemented are slowing
> down (if not preventing) "scratch your own itch" contributions. The CLA
> has been identified as the cause for this but after carefully looking at
> our development processes and the documentation, I think that's only one
> part of the problem (and maybe not even as big as initially thought).

CLAs are a well known and documented barrier to casual contributions
(just look at all the project harmony discussion),  they affect one offs
disproportionately since they require an investment of effort to
understand and legal resources are often unavailable to individuals.
The key problem for individuals in the US is usually do I or my employer
own my contribution?  Because that makes a huge difference to the
process for signing.

> The gerrit workflow for example is something that requires quite an
> investment in time and energy and casual developers (think operators
> fixing small bugs in code, or documentation) have little incentive to go
> through the learning curve.

I've done both ... I do prefer the patch workflow to the gerrit one, but
I think that's just because the former is what I used for ten years and
I'm very comfortable with it.  The good thing about the patch workflow
is that the initial barrier is very low.  However, the later barriers
can be as high or higher.

> To go back in topic, to the proposal to split drivers out of tree, I
> think we may want to evaluate other, simpler, paths before we embark in
> a huge task which is already quite clear will require more cross-project
> coordination.
> 
> From conversations with PTLs and core reviewers I get the impression
> that lots of drivers contributions come with bad code.

Bad code is a bit of a pejorative term.  However, I can sympathize with
the view: In the Linux Kernel, drivers are often the biggest source of
coding style and maintenance issues.  I maintain a driver subsystem and
I would have to admit that a lot of code that goes into those drivers
that wouldn't be of sufficient quality to be admitted to the core kernel
without a lot more clean up and flow changes.  However, is this bad
code?  It mostly works, so it does the job it's designed for.  Usually
the company producing the device is the one maintaining the driver so as
long as they have the maintenance burden and do their job there's no
real harm.  It's a balance, and sometimes I get it wrong, but I do know
from bitter effort that there's a limit to what you can get busy
developers to do in the driver space.

>  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 think it's a question of communities, like Daniel said.  In the
kernel, the driver reviewers are a different community from the core
kernel code reviewers.  Most core reviewers would probably fry their own
eyeballs before they'd review device driver code.  So the solution is
not to make them; instead we set up a review community of people who
understand driver code and make allowances for some of its
eccentricities.  At the end of the day, bad code is measured by defect
count which impacts usability for drivers and the reputation of that
driver is what suffers.  I'm sure in OpenStack, driver reputation is an
easy way to encourage better drivers ... after all hypervisors are
pretty fungible: if the Bar hypervisor driver is awful, you can use the
Foo hypervisor instead.  People who want you to switch to the Baz
hypervisor would need to make sure you have a pretty awesome experience
when you take it for a spin, so they're most naturally inclined to spend
the time writing good code.

To me, this means you don't really want a sin bin where you dump drivers
and tell them not to come out until they're fit to be reviewed by the
core; You want a trusted driver community which does its own reviews and
means the core doesn't have to review them.

James