| 1 |
On Wed, 2006-10-04 at 07:00 -0400, 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. No one seems to have |
| 5 |
> pin pointed the problem, but it seems glaringly obvious to me. We |
| 6 |
> simply don't have enough developers to support the many projects that |
| 7 |
> we have. Here are my ideas for fixing this problem: |
| 8 |
> |
| 9 |
> - Cut the number of packages in half (put the removed ebuilds in |
| 10 |
> community run overlays) |
| 11 |
|
| 12 |
I'm not sure that this really would solve much of anything. I do agree |
| 13 |
that putting removed ebuilds in community-run overlays isn't a bad idea, |
| 14 |
but reducing the number of packages for the sake of reducing does |
| 15 |
nothing more than decrease the usefulness of Gentoo to many people. |
| 16 |
|
| 17 |
> - Formal approval process (or at least strict criteria) for adding |
| 18 |
> new packages |
| 19 |
|
| 20 |
This sounds like too much overhead. |
| 21 |
|
| 22 |
> - Make every dev a member of at least 1 arch team |
| 23 |
|
| 24 |
Absolutely not. The last thing that we need from a QA standpoint is |
| 25 |
having every single developer allowed "free reign" for marking their own |
| 26 |
packages stable, then completely ignoring bugs for any packages that are |
| 27 |
not their own. |
| 28 |
|
| 29 |
> - Double the number of developers with aggressive recruiting |
| 30 |
|
| 31 |
Why do people think that this is a good idea? I have a different one. |
| 32 |
How about we *half* the number of developers, keeping the people who do |
| 33 |
the most work, and let everyone else contribute as members of the |
| 34 |
community? Having developers on projects/teams/herds/whatever that do |
| 35 |
only a few commits a year doesn't do anything but artificially inflate |
| 36 |
our numbers. |
| 37 |
|
| 38 |
> - No competing projects |
| 39 |
|
| 40 |
I wouldn't mind this. The idea of competing *official* projects seems |
| 41 |
rather ludicrous. Of course, to counter this, we would need some way to |
| 42 |
create "semi-official" projects. Projects that are supported within |
| 43 |
themselves but not by "Gentoo" as a whole. This would allow for |
| 44 |
multiple teams to create projects that competed, but then let time and |
| 45 |
actual usage decide which (if any) becomes official. |
| 46 |
|
| 47 |
> - New projects must have 5 devs, a formal plan, and be approved by the |
| 48 |
> council |
| 49 |
|
| 50 |
I only agree to the second of these three points. Projects should have |
| 51 |
a plan. The council definitely should not be a bottleneck in starting |
| 52 |
new projects, unless someone was going to start paying us so we can meet |
| 53 |
all the time to make all these decisions. ;] |
| 54 |
|
| 55 |
> - Devs can only belong to 5 projects at most |
| 56 |
|
| 57 |
This is a really bad idea. Some developers simply work |
| 58 |
harder/faster/more than others. Setting up some artificial limitation |
| 59 |
on how many projects one can belong to won't help. Perhaps a better |
| 60 |
solution here is that all developers must belong to at least one |
| 61 |
project? Coupled with this would be that there would be certain |
| 62 |
expectations within the project for work completed. Developers who do |
| 63 |
not meet the "quota" are removed from the project. Get removed from all |
| 64 |
your projects and get retired. Simple as that. |
| 65 |
|
| 66 |
> - Drop all arches and Gentoo/Alt projects except Linux on amd64, |
| 67 |
> ppc32/64, sparc, and x86 |
| 68 |
|
| 69 |
Quite honesty, Gentoo/BSD (for example) has been excellent in finding |
| 70 |
issues with quality on many packages/ebuilds. The same can be said for |
| 71 |
many of the architectures. Also, remember that there's a difference |
| 72 |
between our supported architectures/projects and our unsupported ones. |
| 73 |
|
| 74 |
> - Reduce the number of projects by eliminating the dead, weak, |
| 75 |
> understaffed, and unnecessary projects |
| 76 |
|
| 77 |
This would be highly subjective. Who would do this? |
| 78 |
|
| 79 |
> - Project status reports once a month for every project |
| 80 |
|
| 81 |
To whom? |
| 82 |
|
| 83 |
-- |
| 84 |
Chris Gianelloni |
| 85 |
Release Engineering Strategic Lead |
| 86 |
Alpha/AMD64/x86 Architecture Teams |
| 87 |
Games Developer/Council Member/Foundation Trustee |
| 88 |
Gentoo Foundation |
Archives