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

[wireless]

On 07/09/2015 10:45 AM, Alec Warner wrote:
>
>
> On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman <rich0@g.o
> <mailto:rich0@g.o>> wrote:
>
>     On Thu, Jul 9, 2015 at 5:31 AM, hasufell <hasufell@g.o
>     <mailto: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 think everybody is getting a bit heated over CI/Quality/automation, 
when clearly there is no good reason to get so heated. Let me explain. 
YES industry, commercial, research, FOSS and everybody is moving to some 
sort of paradigm where as much automation of code examination is 
streamline. Surely these efforts are a work in progress and as such will 
evolved over time. It does not mean the existing, wonderfully manual 
processes are being replaced, it just means that the simple, routine, 
(scriptable if you like) filters are automated. In fact those manual 
processes still need to occur, because the next generation of coders 
have to learn how things work in order to extent the paradigm.


Resources. Surely the major arches are at an advantage. But the current 
cluster offerings are soon going to render very powerful processing so 
even gargantuan, single threaded codes can be automated for CI, quality, 
security etc etc. Both a cross-compile and native compile strategy needs 
to experimented with. Those smaller arches will follow the bigger 
arches; so in that we should just let x86 and other such arches blaze 
the path for gentoo (in a non binding manner) while the various other 
arches (with more humble resources) figure out how to build clusters on 
these other arches. Lots of folks are clustering smalller arches to get 
big tasks back into the realm of viability.


The big benefit for those other (more constrained arches) is that folks 
that build embedded products on those arches will be very, very 
interested in work on how to build a cluster, specific to those (sub) 
arches for CI/quality/security. In fact mesos-distcc does not limit the 
various arch types. So I would think all arches would get on-board and 
just follow this paradigm in an easy, non-stressful manner. But the 
Gentoo leadership does have a responsibility to include those other 
arches in just how this occurs, during some extended transition period, 
so that these other arch's still fell like they are part of this 
extended gentoo family. Loosing those arches would be a horrible damage 
to gentoo's reputation, imho. That is our diversity in arches is 
something gentoo is widely know for and sets us apart, imho.



hth,
James