Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kumba]

Thomas Cort wrote:
> There have been a number of developers leaving Gentoo in the past 6
> months as well as a number of news stories on DistroWatch, Slashdot,
> LWN, and others about Gentoo's internal problems. No one seems to have
> pin pointed the problem, but it seems glaringly obvious to me. We
> simply don't have enough developers to support the many projects that
> we have. Here are my ideas for fixing this problem:
>
> - Cut the number of packages in half (put the removed ebuilds in
> community run overlays)

I doubt this'll work.  I sorta see the portage tree like a starfish -- cut it in 
half, and within time, you get two starfish.  Cut it into three parts, and you 
eventually get three starfish.  You wind up back at square one with double the 
trouble and none of the fun.



> - Formal approval process (or at least strict criteria) for adding
> new packages

This might work, but it depends on what criteria/process, and how well its enforced.


> - Make every dev a member of at least 1 arch team

This won't work -- especially if the dev lacks access to the hardware.  Some 
arches are so complex, you need several types of hardware.  In mips, for 
example, if a dev's got access to a low-end box like an Indy or an O2, then 
letting them help out on basic keywording on common packages probably won't 
hurt, but it would be much better if they had access to say, more than one type 
of mips hardware (say, an Octane, and a Cobalt).

Also, not every dev would want to have to maintain another box of some 
obscure/strange arch.  It's opposite in my case -- I have 1 x86 box running 
Linux (not counting my main desktop since its in windows), and everything else 
is an SGI box (or my one cobalt).  I've got spare parts lying around to build 
two more functional x86 systems, but I've never seen a need to put'em together 
and run them continuously.


> - Double the number of developers with aggressive recruiting

This can become a slippery slope real fast.


> - Devs can only belong to 5 projects at most

I can see this having its uses, but this is more of a personal thing on a 
per-dev basis.


> - Drop all arches and Gentoo/Alt projects except Linux on amd64,
> ppc32/64, sparc, and x86

Uh, no?  Although we sometimes seem as inactive as hell, mips is very much an 
alive arch.  We're a tad guilty of going off and doing our own thing sometimes, 
but then again, most of us are guilty of that at some point in our devship.

I would instead opt for more interaction among archs, probably through dev 
sharing and such.  sparc and mips share several developers (or did, I think I'm 
one of the few left), and encouraging more publicity for the lesser archs.  I 
occasionally post an announcement about some neat new whizbang thing I do (like 
the X LiveCD for SGI systems I might post about tomorrow), and though I rarely 
see a response, I feel it gets the word out.


> - Reduce the number of projects by eliminating the dead, weak,
> understaffed, and unnecessary projects

Depends on the definition of "unnecessary".


> - Project status reports once a month for every project

Hmm, could be useful.  Depends on whether one defines a report as needing to 
match some obscure DoD specification, or whether a simple paragraph or two works 
fine.



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@g.o mailing list