1 |
On Wed, 2007-04-11 at 00:05 +0300, Alon Bar-Lev wrote: |
2 |
> I don't think this is the reason people are leaving. |
3 |
|
4 |
Agreed. |
5 |
|
6 |
> I think people are leaving because a lack of direction. |
7 |
|
8 |
I also agree here, but only to an extent. |
9 |
|
10 |
> I am not aware of any goal Gentoo distribution wish to acquire. For |
11 |
> example: Do we wish to use a mainstream distribution? Do we aim to a |
12 |
> specific user community? Or Do we develop distribution for our use? |
13 |
|
14 |
Currently, we do not have any real global goals set out. |
15 |
|
16 |
> If you wish to be (And I think we should be) mainstream distribution, |
17 |
> we should derive targets, such as QA level, response times and |
18 |
> content. |
19 |
|
20 |
I agree that we should definitely have some measurable goals. |
21 |
|
22 |
> Being more modular is one technical feature to achieve better |
23 |
> stability. But we should discuss the basics first. |
24 |
|
25 |
Being modular in the sense of being able to easily replace code, sure. |
26 |
Being modular in the sense stated by Alexandre, I'm not sure. I just |
27 |
don't see how making everybody entirely independent will help us work |
28 |
together. It just seems so counter-productive to the idea of |
29 |
cooperation to artificially separate people off into smaller |
30 |
territories. |
31 |
|
32 |
> I hear a lot that open source project with unpaid developers cannot be |
33 |
> committed to deadlines or requirements from its developers, but I |
34 |
> disagree. There can be an open source project with high quality |
35 |
> products and dead lines, if these properly defined. |
36 |
|
37 |
Agreed. It works quite well within our own ranks, even, with Release |
38 |
Engineering. The only time we really miss deadlines are due to |
39 |
technical reasons (security, things being broken, etc) that are |
40 |
unforeseen. |
41 |
|
42 |
> I must disclose that in my view whenever a large group of people are |
43 |
> doing something together, some kind of hierarchy must be in place. And |
44 |
> I am not talking about current council, it seems that current council |
45 |
> does not LEAD Gentoo anywhere. |
46 |
|
47 |
I agree that we need a formal hierarchy, but must protest that the |
48 |
current Council doesn't lead. The problem is that every time we *try* |
49 |
to lead, we get a ton of developer backlash, which leads to things like |
50 |
this proposal to try to reduce the Council's ability to lead. So which |
51 |
is it? Do people want the Council to lead or not? If the answer is no, |
52 |
then why do we even *have* a Council? |
53 |
|
54 |
> I read that sometime in history there was an effort to impose |
55 |
> structural format on the community, but then Daniel Robbins left? |
56 |
|
57 |
It was the structure that we had between Daniel leaving and the current |
58 |
Council, and it was pretty much a disaster. The ineffectual nature of |
59 |
that structure is what led us to the current structure. |
60 |
|
61 |
> If we wish to be a major distribution, we must grow. If we to grow we |
62 |
> must organize our-self better, and work toward a common goal. Common |
63 |
> goal forces decision making. Decision making forces leadership. |
64 |
> Leadership forces vision. |
65 |
|
66 |
I tend to think that a "common goal" isn't necessarily something that we |
67 |
need. We do need direction, but I don't think that everyone needs to be |
68 |
working towards the same goals, especially when we have projects that |
69 |
are "at odds" with each other. If we focus on being the best desktop |
70 |
distribution, what happens to embedded? Instead, we need several |
71 |
directions, based on functional differences. |
72 |
|
73 |
Via this sort of breakdown I could see the following: |
74 |
|
75 |
Core system |
76 |
Desktop |
77 |
Server/Hardened |
78 |
Embedded |
79 |
Documentation |
80 |
Release Engineering |
81 |
|
82 |
Even these are not static. They could be changed fairly easily. These |
83 |
groupings are done entirely by function. If we were to think of this as |
84 |
a client/provider relationship, there would be certain functional |
85 |
dependencies. Everybody would depend on the Core system group. |
86 |
Everybody would depend on documentation. Release Engineering would |
87 |
depend on everyone else. Each of these different groups would easily be |
88 |
able to have their own goals and visions, just like divisional units |
89 |
within a company can have different goals. Core system would be |
90 |
interested in solidifying and stabilizing the core of Gentoo. Desktop |
91 |
would be working towards making Gentoo more friendly to desktop users. |
92 |
While the goals aren't necessarily mutually exclusive, they're |
93 |
different. The same could be said for any of the other groups. |
94 |
|
95 |
> Is there any vision? |
96 |
|
97 |
Of course there is some vision. The Council has plenty of ideas and |
98 |
lots of ways where we can lead Gentoo. Why don't we? Because, quite |
99 |
frankly, we're sick of the miles of bullshit attached to every single |
100 |
minor decision made. I'm speaking not for every member of the Council, |
101 |
but from my own perceptions and from the grumblings I've heard from many |
102 |
other Council members during conversations. |
103 |
|
104 |
> Now, for your idea. |
105 |
> When I written something similar in the past, someone told me that it |
106 |
> was already suggested... I don't know why it wasn't accepted. |
107 |
|
108 |
I still think it's a fairly good idea for how Gentoo should be |
109 |
organized. I just don't see how changing our organization will solve |
110 |
our most pressing current issues. I'd rather clean the house up a bit |
111 |
before we decide to try to remodel it. |
112 |
|
113 |
<snip> |
114 |
|
115 |
The ideas of having differing metrics for different packages is really a |
116 |
good one. It doesn't require overlays to accomplish, either. The only |
117 |
real problem I see with it is determining how to rate the packages. |
118 |
|
119 |
> But I believe we should first discuss the community goals, then derive |
120 |
> a technical solution. |
121 |
|
122 |
Agreed. |
123 |
|
124 |
-- |
125 |
Chris Gianelloni |
126 |
Release Engineering Strategic Lead |
127 |
Alpha/AMD64/x86 Architecture Teams |
128 |
Games Developer/Council Member/Foundation Trustee |
129 |
Gentoo Foundation |