Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[hasufell]

On 07/09/2015 01:47 PM, Rich Freeman wrote:
> On Thu, Jul 9, 2015 at 5:31 AM, hasufell <hasufell@g.o> wrote:
>>
>> The quality problem is that we have too many developers. If you make
>> community contributions easier, sane and more reliable (due to code
>> review) then you solve several problems at once, because you need _less_
>> developers. Are you aware that we could potentially "pull" in hundreds
>> of contributors who chose to work on their personal overlay instead of
>> the gentoo tree? Are you aware that there are a lot of those people?
>
> Yes and no.
>
> I'll agree that with a review workflow we might only need one reviewer
> for every 10 contributors, or something like that.  If we have 100
> active devs today, in theory we could instead turn 20 of them into
> reviewers, and now we can support 2000 contributors.
>
> There are some big assumptions with this kind of argument, though:
> 1.  We might find that we don't even have 20 devs interested in doing
> a substantial amount of review.
> 2.  The main repository is very diverse.  If 50% of our packages have
> only one person interested in maintaining them, then they get dropped
> since reviewers will ignore their contributions.  Or, they'll just
> rubber-stamp them which is adding valueless work.
>
> So, a review system could make manpower either more of an issue or
> less of one.  I suspect that trying to force it would basically end up
> putting the entire distro on hold until most of the current devs quit,
> and a new crop signs up who is interested in using the new workflow,
> and then they're starting with zero experience.
>
> I think a review model is best implemented by individual project
> teams.  They could use it to track changes in an overlay or branch in
> the main tree, and then move those into the main tree using whatever
> quality system seems best.  The team can figure out what is working
> best for it, and if over time a large number of devs feel that it is a
> good way to work we could then talk about doing it with the main tree.
> I still suspect we'll end up having problems with the 70% of packages
> that don't fall into a project though.
>

I'm not sure if you followed my argumentation. I basically said that it
is unrealistic to enforce a review-only workflow and that it should/can
start within gentoo-internal projects. You are just repeating what I
already said.

My point was that I am not mixing up different issues as Andrew claimed,
because a review workflow can be seen in a different context.
And then, the repeated argument of "not enough manpower for review
workflow" doesn't make a lot of sense. The problem is the mindest/culture.

However, it makes sense to provide review workflow tools. And they have
been demanded quite a few times now I think, even from vapier afair.