On 07/09/2015 10:45 AM, Alec Warner wrote:
On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman <ri...@gentoo.org <mailto:ri...@gentoo.org>> wrote: On Thu, Jul 9, 2015 at 5:31 AM, hasufell <hasuf...@gentoo.org <mailto:hasuf...@gentoo.org>> 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
