1 |
On Tue, Jan 20, 2015 at 11:00 PM, hasufell <hasufell@g.o> wrote: |
2 |
> 2. Make gentoo more decentralized and reduce the number of core-devs to |
3 |
> allow conflicting ideas which is one of the main points of GLEP 39, IMO. |
4 |
> But now make this idea actually possible on the technical and |
5 |
> methodology level. |
6 |
|
7 |
You've talked about the first sentence in this suggestion before, but |
8 |
not really about the second. Just what does making this possible from |
9 |
a technical level look like, other than how things work today? How |
10 |
can we have both games.eclass and no games.eclass but due to a |
11 |
technical/methodology change there are now less problems? Ditto for |
12 |
the two multilib implementations? |
13 |
|
14 |
It seems to me that your #2 and #1 are really the same thing - having |
15 |
fewer core devs actually eliminates conflicting ideas and increases |
16 |
focus, simply by virtue of the fact that there are fewer people left |
17 |
to disagree. It is nice to speak of having your cake and eating it |
18 |
too, but saying it doesn't make it happen, and I don't want a |
19 |
bait-and-switch where we sell everybody on a concept but then say, |
20 |
"well, there was no way this was ever going to work out like we talked |
21 |
about..." |
22 |
|
23 |
My main concern with this approach is that it seems reasonably likely |
24 |
to just result in having zero devs. When I've seen big shakeups in |
25 |
other organizations with the goal of revitalizing things the result is |
26 |
often that the organization just disbands. The chances of a new |
27 |
person becoming committed tends to be low, while the chance of an |
28 |
existing contributor remaining committed is much higher. Anytime you |
29 |
shake things up you tend to have far more to lose than to gain as a |
30 |
result. |
31 |
|
32 |
I think that a major shakeup only makes sense if we can actually |
33 |
demonstrate a new model in operation, and it actually solves our |
34 |
problems. |
35 |
|
36 |
-- |
37 |
Rich |