On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort <[EMAIL PROTECTED]> 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. Regarding the news stories - they're just ill-informed sensationalist press (nothing new there, then). If a news site feels the need to report when dev X leaves in a tantrum, it says more about the amount and quality of news they have to report than it does about us. > 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. One problem is that some expect all work to be done immediately. The only stuff that has to be done asap is security fixes; everything else can be done when it's good and ready. > Here are my ideas for fixing this problem: > > - Cut the number of packages in half (put the removed ebuilds in > community run overlays) We already have TreeCleaners who have a managed approach to removing unmaintained&broken ebuilds. What cuts are you proposing in addition to that, and why? > - Formal approval process (or at least strict criteria) for adding > new packages Yuck. Devs should be free to add whatever packages they like, provided they're willing to maintain them. I'd support stronger QA of ebuilds. Of course that's down to finding enough clue-ful people willing to join the QA team and do the reviews. > - Make every dev a member of at least 1 arch team Why? The only people on arch teams should be those actually doing arch work. Many devs don't get involved in stable keywording, and there's no reason they should be - why should they be on an arch team? > - Double the number of developers with aggressive recruiting Assuming we need more devs, the issues are (1) supply of good people and (2) resource in recruiters. (1) is the crux of the problem. No amount of wand waving is going to change that. > - No competing projects Absolutely disagree. At worst, if two projects cannot physically co-exist in the same tree then they should go into overlay, but we've yet to see that. > - New projects must have 5 devs, a formal plan, and be approved by the > council To what end? Just to make new projects harder to form? There is rather a lot of argument about nascent projects - I'd rather see such discussion happen when projects reach the stage that they have something solid to add. Support for dev and project overlays helps a lot, as it provides a workspace for progressing projects without causing daily disruption to the tree. > - Devs can only belong to 5 projects at most Why? That achieves nothing. The number of projects a dev belongs to is down to the dev and the projects involved. > - Drop all arches and Gentoo/Alt projects except Linux on amd64, > ppc32/64, sparc, and x86 You are joking, aren't you? If you're worried about keywording, the critical arches are x86, ppc, amd64 - which is where you see most comments about slowness of stabilisation. The "minority" arches like mips, sparc etc seem to get along quite happily. > - Reduce the number of projects by eliminating the dead, weak, > understaffed, and unnecessary projects Dead: if you mean projects that no-one uses anymore and are no longer developed, then fine, they're candidates for deletion. Weak: Be more specific. What are the "weak" projects, and why? Understaffed: this issue manifests itself as a project being slow to update. However the only place this is an issue is for security issue management. Another solution to under-staffing is to reduce expectations. Unnecessary: again, be more specific. What are the "unnecessary" projects, and why? > - Project status reports once a month for every project We've discussed this before. Project status reports make sense if they're going to be read. Personally I think each project should organise its own status reporting schedule. -- Kevin F. Quinn
signature.asc
Description: PGP signature
