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.
People come and go, I still see Gentoo going forward, packages still get updated, work gets done... So I'm really beginning to think people read toooo much into a few people leaving over 6 months and a few, generally wrong articles based on misinterpreting someones blog... > simply don't have enough developers to support the many projects that > we have. Here are my ideas for fixing this problem: Maybe, maybe not... Projects exist, so there is at least _someone_ that's interested in them... If that's not true, then ok, just remove that project... Let's start the comments on the 10 points (all imho): > - Cut the number of packages in half (put the removed ebuilds in > community run overlays) Who decides what goes away and what now? Which criteria is used here? Btw, this is already being done splendidly by the TreeCleaners project, and Sunrise and other overlays are already absorbing stuff from the community. > - Formal approval process (or at least strict criteria) for adding > new packages Err what? So I, as a dev, that did quizzes, etc., cannot even anymore just add the package that has got my fancy atm, because there are some criteria to what is added and what not, and I have to go through a bureaucratic process just for that? Never! If for strict criteria you mean "there must be at least a dev or herd maintaining it", or such stuff, they already exist, they may just need some more enforcing... ;) > - Make every dev a member of at least 1 arch team Which doesn't mean he will ever keyword stuff stable, other than his own, which he already can... Let's face it: most devs are mainly interested in their stuff, getting their stuff keyworded, and many wouldn't anyway have the time to efficiently work on an arch-team, as members of such I mean, not just as "I'm a member, so I keyword my stuff, that's it"... For that I agree with the current practice: if you want that, ask the arch-team first. ;) > - Double the number of developers with aggressive recruiting That's something that goes on since... forever! Gentoo's continuously recruiting new people, more aggressive recruiting has already been proposed many times, but it was always agreed to try to maintain a relatively high standard of new recruits, and if you want quality, finding loads of people who "just happen" to have the time and dedication to become a Gentoo dev isn't that easy. > - No competing projects Kills innovation... Who comes first has total monopoly of that branch of things basically... I'd never agree to something like this, personally. > - New projects must have 5 devs, a formal plan, and be approved by the > council New projects do always have a plan, they wouldn't be created else... ;) Making it formal, be approved by the council... How to slow everything down? We continuously see how adding bureaucratic stuff just suffocates innovation, I totally agree with discussion et all, but not really on the need to have everything approved by someone (the council in this case)... The council may kill the project later on if it's doing totally crazy shit, but that's another thing entirely... > - Devs can only belong to 5 projects at most Why? If someone has time to dedicate and work on a lot of projects, why not? > - Drop all arches and Gentoo/Alt projects except Linux on amd64, > ppc32/64, sparc, and x86 Uhhh is this real? How would this help at all? Hell, it would make things worse to an extent, we've already seen that at least Gentoo/BSD helped in finding problems in ebuilds using too GNUish stuff, other arches may help in finding broken code, etc.. I'd agree with some proposal to relax keywording policy for all arches you've not listed, since on those others, sadly, not soo many people are active, and you get to wait on keywords for months sometimes... This is something we should imo address from an arch-team PoV, some kind of "if they don't react in time, I can drop their keyword back to unstable or entirely", or something like that, that would help many package maintainers I think. > - Reduce the number of projects by eliminating the dead, weak, > understaffed, and unnecessary projects Again, who's the judge of that? If there is a project with at least one person active, it means for him it's not unnecessary... What means weak project? What's unnecessary? Sure, kill the dead ones with no activity and no active members, that's easy and I agree with that, but the other, little ones, who's the one to say "you're understaffed and useless, go die!"? :S > - Project status reports once a month for every project Totally agree on this one! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
