1 |
Donnie Berkholz: |
2 |
> On 14:41 Thu 15 Jan , hasufell wrote: |
3 |
>> How do you want to _ensure_ focus with 263 developers having direct |
4 |
>> push access without any strict review policies? |
5 |
>> |
6 |
>> How do you want to ensure focus if the council and GLEP 39 say that we |
7 |
>> may have conflicting ideas in ONE single repository and that we may |
8 |
>> voluntarily break tree consistency (can give examples)? |
9 |
> |
10 |
> I discussed some of this, in terms of what specifically "focus" would |
11 |
> look like, in my response to Daniel. |
12 |
> |
13 |
>> You are tackling the wrong problem. The problem is not lack of ideas and |
14 |
>> people having focus on these ideas. |
15 |
> |
16 |
> Instead, it is...? |
17 |
> |
18 |
|
19 |
Sorry to answer so late. I didn't have the time yet. |
20 |
|
21 |
The main problem in my opinion is that our organizational concept as a |
22 |
whole doesn't work so well... or at least not any more. With concept I |
23 |
don't just mean focus on technical stuff, but the question where does |
24 |
that focus come from and how do we process ideas? |
25 |
|
26 |
As I said... we have a lot of people with ideas and some are very |
27 |
focussed. Ofc we can discuss a technical focus and you/we might even be |
28 |
lucky and the majority agrees with you... now. And in 3 months? |
29 |
|
30 |
Afais gentoo is a very loose group of devs with optional communication, |
31 |
but everyone having access to one repository. Conflicting ideas and |
32 |
inconsistencies are allowed, unless it's about EAPI. Maybe this has |
33 |
worked for some time, but I think that was rather coincidence. |
34 |
And this has lead to several problems: |
35 |
1. very high bus factor in some areas (as in: lets not hope mgorny, |
36 |
vapier or jer quit gentoo... commit rate will go down a lot or bugzilla |
37 |
just die) |
38 |
2. point 1 also resulted into some devs getting special privileges which |
39 |
sometimes amplifies point 7 |
40 |
3. low QA |
41 |
4. difficult collaboration model |
42 |
5. major conflicting ideas not being properly mediated: e.g. multilib vs |
43 |
portage-multilib, because portage-multilib wasn't in-tree anyway and |
44 |
multilib was an eclass concept |
45 |
6. allowing inconsistencies that may break user experience: e.g. we have |
46 |
games.eclass, but the council says... well, you may or may not use it |
47 |
(instead of saying we wipe it out completely or we follow the concept of |
48 |
special permissions consistently) |
49 |
7. a lot of organizational problems these days and a high burn-out rate |
50 |
for people who come up with new ideas |
51 |
|
52 |
I think there are only two ways out of it: |
53 |
1. Make gentoo more centralized to ensure focus. One possibility would |
54 |
be to give a lot more power to the council and make it the main hive for |
55 |
new ideas (already proposed that a year or more ago during council |
56 |
election, afair). |
57 |
2. Make gentoo more decentralized and reduce the number of core-devs to |
58 |
allow conflicting ideas which is one of the main points of GLEP 39, IMO. |
59 |
But now make this idea actually possible on the technical and |
60 |
methodology level. |
61 |
This would imply a major restructuring of the organizational model and a |
62 |
redefinition of "core development", which would also ensure focus of |
63 |
that core development. (already proposed this a few weeks/months ago) |
64 |
|
65 |
I think we are currently a hybrid of both concepts and I think that is a |
66 |
problem. It's not enough to come up with ideas to focus on. You also |
67 |
have to come up with a way to ensure focus... or a way that doesn't need |
68 |
to ensure focus, at least for some areas. |