| 1 |
Thomas Cort wrote: |
| 2 |
> There have been a number of developers leaving Gentoo in the past 6 |
| 3 |
> months as well as a number of news stories on DistroWatch, Slashdot, |
| 4 |
> LWN, and others about Gentoo's internal problems. |
| 5 |
|
| 6 |
People come and go, I still see Gentoo going forward, packages still get |
| 7 |
updated, work gets done... So I'm really beginning to think people read |
| 8 |
toooo much into a few people leaving over 6 months and a few, generally |
| 9 |
wrong articles based on misinterpreting someones blog... |
| 10 |
|
| 11 |
> simply don't have enough developers to support the many projects that |
| 12 |
> we have. Here are my ideas for fixing this problem: |
| 13 |
|
| 14 |
Maybe, maybe not... Projects exist, so there is at least _someone_ |
| 15 |
that's interested in them... If that's not true, then ok, just remove |
| 16 |
that project... Let's start the comments on the 10 points (all imho): |
| 17 |
|
| 18 |
> - Cut the number of packages in half (put the removed ebuilds in |
| 19 |
> community run overlays) |
| 20 |
|
| 21 |
Who decides what goes away and what now? Which criteria is used here? |
| 22 |
Btw, this is already being done splendidly by the TreeCleaners project, |
| 23 |
and Sunrise and other overlays are already absorbing stuff from the |
| 24 |
community. |
| 25 |
|
| 26 |
> - Formal approval process (or at least strict criteria) for adding |
| 27 |
> new packages |
| 28 |
|
| 29 |
Err what? So I, as a dev, that did quizzes, etc., cannot even anymore |
| 30 |
just add the package that has got my fancy atm, because there are some |
| 31 |
criteria to what is added and what not, and I have to go through a |
| 32 |
bureaucratic process just for that? Never! |
| 33 |
If for strict criteria you mean "there must be at least a dev or herd |
| 34 |
maintaining it", or such stuff, they already exist, they may just need |
| 35 |
some more enforcing... ;) |
| 36 |
|
| 37 |
> - Make every dev a member of at least 1 arch team |
| 38 |
|
| 39 |
Which doesn't mean he will ever keyword stuff stable, other than his |
| 40 |
own, which he already can... Let's face it: most devs are mainly |
| 41 |
interested in their stuff, getting their stuff keyworded, and many |
| 42 |
wouldn't anyway have the time to efficiently work on an arch-team, as |
| 43 |
members of such I mean, not just as "I'm a member, so I keyword my |
| 44 |
stuff, that's it"... For that I agree with the current practice: if you |
| 45 |
want that, ask the arch-team first. ;) |
| 46 |
|
| 47 |
> - Double the number of developers with aggressive recruiting |
| 48 |
|
| 49 |
That's something that goes on since... forever! Gentoo's continuously |
| 50 |
recruiting new people, more aggressive recruiting has already been |
| 51 |
proposed many times, but it was always agreed to try to maintain a |
| 52 |
relatively high standard of new recruits, and if you want quality, |
| 53 |
finding loads of people who "just happen" to have the time and |
| 54 |
dedication to become a Gentoo dev isn't that easy. |
| 55 |
|
| 56 |
> - No competing projects |
| 57 |
|
| 58 |
Kills innovation... Who comes first has total monopoly of that branch of |
| 59 |
things basically... I'd never agree to something like this, personally. |
| 60 |
|
| 61 |
> - New projects must have 5 devs, a formal plan, and be approved by the |
| 62 |
> council |
| 63 |
|
| 64 |
New projects do always have a plan, they wouldn't be created else... ;) |
| 65 |
Making it formal, be approved by the council... How to slow everything |
| 66 |
down? We continuously see how adding bureaucratic stuff just suffocates |
| 67 |
innovation, I totally agree with discussion et all, but not really on |
| 68 |
the need to have everything approved by someone (the council in this |
| 69 |
case)... The council may kill the project later on if it's doing totally |
| 70 |
crazy shit, but that's another thing entirely... |
| 71 |
|
| 72 |
> - Devs can only belong to 5 projects at most |
| 73 |
|
| 74 |
Why? If someone has time to dedicate and work on a lot of projects, why not? |
| 75 |
|
| 76 |
> - Drop all arches and Gentoo/Alt projects except Linux on amd64, |
| 77 |
> ppc32/64, sparc, and x86 |
| 78 |
|
| 79 |
Uhhh is this real? How would this help at all? Hell, it would make |
| 80 |
things worse to an extent, we've already seen that at least Gentoo/BSD |
| 81 |
helped in finding problems in ebuilds using too GNUish stuff, other |
| 82 |
arches may help in finding broken code, etc.. I'd agree with some |
| 83 |
proposal to relax keywording policy for all arches you've not listed, |
| 84 |
since on those others, sadly, not soo many people are active, and you |
| 85 |
get to wait on keywords for months sometimes... This is something we |
| 86 |
should imo address from an arch-team PoV, some kind of "if they don't |
| 87 |
react in time, I can drop their keyword back to unstable or entirely", |
| 88 |
or something like that, that would help many package maintainers I think. |
| 89 |
|
| 90 |
> - Reduce the number of projects by eliminating the dead, weak, |
| 91 |
> understaffed, and unnecessary projects |
| 92 |
|
| 93 |
Again, who's the judge of that? If there is a project with at least one |
| 94 |
person active, it means for him it's not unnecessary... What means weak |
| 95 |
project? What's unnecessary? Sure, kill the dead ones with no activity |
| 96 |
and no active members, that's easy and I agree with that, but the other, |
| 97 |
little ones, who's the one to say "you're understaffed and useless, go |
| 98 |
die!"? :S |
| 99 |
|
| 100 |
> - Project status reports once a month for every project |
| 101 |
|
| 102 |
Totally agree on this one! |
| 103 |
-- |
| 104 |
Best regards, |
| 105 |
Luca Longinotti aka CHTEKK |
| 106 |
|
| 107 |
LongiTEKK Networks Admin: chtekk@×××××××××.com |
| 108 |
Gentoo Dev: chtekk@g.o |
| 109 |
SysCP Dev: chtekk@×××××.org |
| 110 |
TILUG Supporter: chtekk@×××××.ch |
Archives