Open Stack

On 09/09/2014 06:55 AM, James Bottomley wrote:
> CLAs are a well known and documented barrier to casual contributions

I'm not convinced about this statement, at all. And since I think it's
secondary to what we're discussing, I'll leave it as is and go on.

> I've done both ... I do prefer the patch workflow to the gerrit one,
[...]

Do you consider yourself a 'committed' developer or a casual one?
Because ultimately I think this is what it comes down to: a developer
who has a commitment to get a patch landed in tree has a different
motivation and set of incentives that make climbing the learning curve
more appealing. A casual contributor is a different persona.

> Bad code is a bit of a pejorative term.

I used the wrong term, I apologize if I offended someone: it wasn't my
intention.

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

thanks for saying this a lot more nicely than my rough expression.

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

I think we're going somewhere here, based on your comment and other's:
we may achieve some result if we empower a new set of people to manage
drivers, keeping them in the same repositories where they are now. This
new set of people may not be the current core reviewers but other with
different skillsets and more capable of understanding the driver's
ecosystem, needs, motivations, etc.

I have the impression this idea has been circling around for a while but
for some reason or another (like lack of capabilities in gerrit and
other reasons) we never tried to implement it. Maybe it's time to think
about an implementation. We have been thinking about mentors
https://wiki.openstack.org/wiki/Mentors, maybe that's a way to go?
Sub-team with +1.5 scoring capabilities?

/stef

-- 
Ask and answer questions on https://ask.openstack.org