| 1 |
On Wed, 4 Oct 2006 07:00:14 -0400 |
| 2 |
Thomas Cort <tcort@g.o> wrote: |
| 3 |
|
| 4 |
> There have been a number of developers leaving Gentoo in the past 6 |
| 5 |
> months as well as a number of news stories on DistroWatch, Slashdot, |
| 6 |
> LWN, and others about Gentoo's internal problems. |
| 7 |
|
| 8 |
Regarding the news stories - they're just ill-informed |
| 9 |
sensationalist press (nothing new there, then). If a news site feels |
| 10 |
the need to report when dev X leaves in a tantrum, it says more about |
| 11 |
the amount and quality of news they have to report than it does about |
| 12 |
us. |
| 13 |
|
| 14 |
> No one seems to have |
| 15 |
> pin pointed the problem, but it seems glaringly obvious to me. We |
| 16 |
> simply don't have enough developers to support the many projects that |
| 17 |
> we have. |
| 18 |
|
| 19 |
One problem is that some expect all work to be done immediately. The |
| 20 |
only stuff that has to be done asap is security fixes; everything else |
| 21 |
can be done when it's good and ready. |
| 22 |
|
| 23 |
> Here are my ideas for fixing this problem: |
| 24 |
> |
| 25 |
> - Cut the number of packages in half (put the removed ebuilds in |
| 26 |
> community run overlays) |
| 27 |
|
| 28 |
We already have TreeCleaners who have a managed approach to removing |
| 29 |
unmaintained&broken ebuilds. What cuts are you proposing in addition |
| 30 |
to that, and why? |
| 31 |
|
| 32 |
> - Formal approval process (or at least strict criteria) for adding |
| 33 |
> new packages |
| 34 |
|
| 35 |
Yuck. Devs should be free to add whatever packages they like, |
| 36 |
provided they're willing to maintain them. |
| 37 |
|
| 38 |
I'd support stronger QA of ebuilds. Of course that's down to finding |
| 39 |
enough clue-ful people willing to join the QA team and do the reviews. |
| 40 |
|
| 41 |
> - Make every dev a member of at least 1 arch team |
| 42 |
|
| 43 |
Why? The only people on arch teams should be those actually doing arch |
| 44 |
work. Many devs don't get involved in stable keywording, and there's |
| 45 |
no reason they should be - why should they be on an arch team? |
| 46 |
|
| 47 |
> - Double the number of developers with aggressive recruiting |
| 48 |
|
| 49 |
Assuming we need more devs, the issues are (1) supply of good people and |
| 50 |
(2) resource in recruiters. (1) is the crux of the problem. No amount |
| 51 |
of wand waving is going to change that. |
| 52 |
|
| 53 |
> - No competing projects |
| 54 |
|
| 55 |
Absolutely disagree. At worst, if two projects cannot physically |
| 56 |
co-exist in the same tree then they should go into overlay, but we've |
| 57 |
yet to see that. |
| 58 |
|
| 59 |
> - New projects must have 5 devs, a formal plan, and be approved by the |
| 60 |
> council |
| 61 |
|
| 62 |
To what end? Just to make new projects harder to form? |
| 63 |
|
| 64 |
There is rather a lot of argument about nascent projects - I'd rather |
| 65 |
see such discussion happen when projects reach the stage that they have |
| 66 |
something solid to add. |
| 67 |
|
| 68 |
Support for dev and project overlays helps a lot, as it provides a |
| 69 |
workspace for progressing projects without causing daily disruption to |
| 70 |
the tree. |
| 71 |
|
| 72 |
> - Devs can only belong to 5 projects at most |
| 73 |
|
| 74 |
Why? That achieves nothing. The number of projects a dev belongs to |
| 75 |
is down to the dev and the projects involved. |
| 76 |
|
| 77 |
> - Drop all arches and Gentoo/Alt projects except Linux on amd64, |
| 78 |
> ppc32/64, sparc, and x86 |
| 79 |
|
| 80 |
You are joking, aren't you? If you're worried about keywording, the |
| 81 |
critical arches are x86, ppc, amd64 - which is where you see most |
| 82 |
comments about slowness of stabilisation. The "minority" arches like |
| 83 |
mips, sparc etc seem to get along quite happily. |
| 84 |
|
| 85 |
> - Reduce the number of projects by eliminating the dead, weak, |
| 86 |
> understaffed, and unnecessary projects |
| 87 |
|
| 88 |
Dead: if you mean projects that no-one uses anymore and are no longer |
| 89 |
developed, then fine, they're candidates for deletion. |
| 90 |
|
| 91 |
Weak: Be more specific. What are the "weak" projects, and why? |
| 92 |
|
| 93 |
Understaffed: this issue manifests itself as a project being slow to |
| 94 |
update. However the only place this is an issue is for security issue |
| 95 |
management. Another solution to under-staffing is to reduce |
| 96 |
expectations. |
| 97 |
|
| 98 |
Unnecessary: again, be more specific. What are the "unnecessary" |
| 99 |
projects, and why? |
| 100 |
|
| 101 |
> - Project status reports once a month for every project |
| 102 |
|
| 103 |
We've discussed this before. Project status reports make sense if |
| 104 |
they're going to be read. Personally I think each project should |
| 105 |
organise its own status reporting schedule. |
| 106 |
|
| 107 |
-- |
| 108 |
Kevin F. Quinn |
Archives