1 |
On Tue, 2007-04-10 at 23:11 +0200, Alexandre Buisse wrote: |
2 |
> Sorry about that, I should have taken the time to look it up. Since I |
3 |
> didn't hear about it after Stuart leaved, I assumed no one was working |
4 |
> on it anymore. |
5 |
|
6 |
Stuart's work had nothing to do with the implementation of stage4. His |
7 |
work was *utilizing* the stage4 target, not implementing it. I don't |
8 |
know about the status of the Seeds project itself, but Release |
9 |
Engineering has been working towards producing similarly-designed stage4 |
10 |
tarballs for some time. It is actually one of the motivators to moving |
11 |
to the desktop/server sub-profiles on the release profiles. |
12 |
|
13 |
> > Will this actually resolve any of the recent problems? |
14 |
> |
15 |
> Yes, as I tried to explain in the proposal. |
16 |
|
17 |
OK. I missed the solutions, then. |
18 |
|
19 |
> > Will this stop flame wars? |
20 |
> |
21 |
> Probably not, but it can help reduce the volume, hopefully. Indirectly, |
22 |
> of course, but I believe it would help a lot to reduce the tensions. |
23 |
|
24 |
Why bother restructuring, then? Why not just dump the gentoo-dev |
25 |
mailing list entirely and have everyone use the individual project lists |
26 |
that already exist for intra-project communications and have no official |
27 |
facility for inter-project or global issues. This sounds like what |
28 |
you're proposing to me, but I may be mistaken. |
29 |
|
30 |
> > Will this cause people be nicer to each other? |
31 |
> |
32 |
> Definitely, yes. Because everyone will work on a smaller scale. |
33 |
|
34 |
This is entirely speculation. The projects will still have to interact |
35 |
to be able to produce a cohesive product (the tree) so I don't see how |
36 |
artificially sectioning people off into their own little worlds will do |
37 |
anything to change the current situation other than possibly make some |
38 |
groups even more closed and xenophobic than they already are today. |
39 |
|
40 |
> > Will this give us more qualified developers? |
41 |
> |
42 |
> Will depend on how each team will do its recruitment. And of course, to |
43 |
> get official status, some kind of council would ensure some minimal |
44 |
> qualifications (along the current guidelines would be my guess). |
45 |
|
46 |
If these projects are still required to follow the same guidelines and |
47 |
still have a centralized Council to guide them, what is changing? |
48 |
|
49 |
> > Will this increase the quality of the tree? |
50 |
> |
51 |
> Hard to tell. Having people leave the project out of disgust certainly |
52 |
> doesn't improve it. |
53 |
|
54 |
Neither does avoiding a direct question. |
55 |
|
56 |
> > Restructuring the project isn't going to solve these problems. |
57 |
> |
58 |
> Not all of them, of course. And I never pretended it would. But I |
59 |
> believe that it would definitely help. |
60 |
|
61 |
How? |
62 |
|
63 |
Please be very verbose in your responses. Vague speculation and |
64 |
guessing isn't necessary. If you're unable to qualify your statements, |
65 |
please don't make them. If we're talking about restructuring the entire |
66 |
project yet again in an attempt to rectify the current social problems |
67 |
Gentoo is facing, I want to know *exactly* why I should consider it and |
68 |
*exactly* what changes you think will occur, including reasoning for |
69 |
thinking such things. |
70 |
|
71 |
> > At best, |
72 |
> > it will mask them during the time that we've wasted restructuring only |
73 |
> > to find that we are back with the same set of problems, though now |
74 |
> > without any form of centralized management to have even the glimmer of |
75 |
> > hope of being able to resolve them. |
76 |
> |
77 |
> I don't see how not having a centralized management would make it |
78 |
> impossible to solve problems. Or are people really that stupid that they |
79 |
> can't manage to get together and reach a decision, in some way or |
80 |
> another (I gave some ideas in the last part of the email as well). Just |
81 |
> giving all your power of decision to a big boss is a very crude and |
82 |
> unefficient way of solving problems. |
83 |
|
84 |
I had a feeling this was going to move in this direction. We have |
85 |
shown, quite well, actually, that there needs to be some form of |
86 |
leadership that is active in the global issues of the distribution. |
87 |
Nobody has ever said *anything* about giving over all decision-making |
88 |
ability to some "boss" group. Your description doesn't match the |
89 |
current state of things and is only used as a way of trying to convince |
90 |
people on an emotional level to agree with you where your statements |
91 |
aren't based on fact. |
92 |
|
93 |
> > It will take us to a complete mess |
94 |
> > of incompatible overlays and trees. |
95 |
> |
96 |
> If we do it carelessly, certainly. But free software has solved much more |
97 |
> complex problems in the past. |
98 |
|
99 |
No offense, but what does that have to do with my statement? |
100 |
|
101 |
Remember that as much as we like to tout Gentoo as a meta-distribution |
102 |
it is *also* a distribution of its own. It needs some kind of cohesion |
103 |
to keep it functioning. One of the things that keeps Gentoo cohesive, |
104 |
even with the current overlays, is that in almost all cases, the |
105 |
overlays for some project, such as Java, are run by the Java team. This |
106 |
means they won't have conflicting things around, since they manage both |
107 |
sides. If suddenly I were to go around creating a ton of Java ebuilds |
108 |
in an overlay, the Java team's overlay would still be the "official" |
109 |
overlay for the team, unless the team decided to adopt mine. How is |
110 |
your proposal any different? Why does *Gentoo* need to encourage |
111 |
competition within its own ranks when we've already shown that the |
112 |
competition can come from outside just as easily, if not more easily? |
113 |
Why not simply keep the "one project per area" that we have currently? |
114 |
Yes, I am aware that we *could* have competing projects doing the same |
115 |
work currently, but what real gain do we have from multiple people doing |
116 |
the same thing? Realize that I'm not talking about competing |
117 |
*alternatives* to each other, like portage/pkgcore/paludis, I'm talking |
118 |
competing teams doing essentially the same work, like having two Java |
119 |
teams. |
120 |
|
121 |
> > It also places the projects in a |
122 |
> > hierarchy that doesn't match the actual power structure. |
123 |
> |
124 |
> Power structure? I'm afraid I don't understand what you mean here. |
125 |
|
126 |
What I meant to say is what is the point in projects being a "sub" or in |
127 |
any way associated with another project if they're not under the same |
128 |
management tree of any kind. This is something that applies currently, |
129 |
too. Why is, for example, games a sub-project of desktop, when the |
130 |
desktop guys don't have any say in what games does? I think a flat |
131 |
project space for these independent projects is best, even with our |
132 |
current structure. At the same time, there *are* some projects that are |
133 |
directly related. A good example of this is Release Engineering and the |
134 |
Installer projects. While the Installer *is* a sub-project of Release |
135 |
Engineering, it is run by the project itself. However, the project |
136 |
*does* get some direction from Release Engineering. The top-level |
137 |
project requests features and other such things, and the sub-project |
138 |
provides them. Now, the project provides them under their own |
139 |
management, in a way entirely of their own choosing, but they still |
140 |
"answer" to Release Engineering in a vague sense. |
141 |
|
142 |
> > If the parent project doesn't govern the sub-project, then why is it a |
143 |
> > sub-project, at all? |
144 |
> |
145 |
> To ease coordination and make obvious relationships clearer, I guess. |
146 |
|
147 |
I'm not sure I see the point. Where do you draw the lines? |
148 |
|
149 |
> Can also help overlay management with hints like "you've pulled the |
150 |
> audio overlay, you probably also want the multimedia one" and stuff like |
151 |
> that. But it isn't really important, and the name "subproject" is |
152 |
> probably misleading. |
153 |
|
154 |
Agreed. I just don't see any need to associate the individual projects |
155 |
if they're not under the same management structure. Sure, people might |
156 |
want to associate projects due to their similarity, but I don't see how |
157 |
associating them politically has anything to do with them being |
158 |
associated technically. A good example here is GNOME/KDE. While both |
159 |
of them are very similar, they really have no need to have any |
160 |
association with each other to get their job done. Just because they're |
161 |
both desktop environments doesn't mean they need political ties. |
162 |
|
163 |
> > What exactly are all of us supposed to actually *do* while we're waiting |
164 |
> > for the SCM conversion and for the package managers to get the support |
165 |
> > necessary and all of the changes are made to the tree? |
166 |
> |
167 |
> Keep working on the current version? I don't know, I would classify that |
168 |
> as an implementation detail to be sorted if we actually decide to go |
169 |
> forward. |
170 |
|
171 |
That seems like an awfully big "detail" to completely gloss over. |
172 |
You're talking about completely changing the way that technical |
173 |
contribution, political structure, and social structure are all done |
174 |
within Gentoo. I think something so disruptive is quite a bit more than |
175 |
an "implementation detail" especially considering it is the subject of |
176 |
your proposal. |
177 |
|
178 |
> > Do we simply |
179 |
> > stop developing the distribution for days? Weeks? Months? |
180 |
> |
181 |
> I'm sure we can find a better solution than that. But do we want to |
182 |
> discuss such tiny details before the big plan itself? |
183 |
|
184 |
We'll just have to disagree that it is a tiny detail, since I see it as |
185 |
probably the most important aspect of your proposal. It's all fine and |
186 |
dandy to speculate on how we could be different, but if there's no way |
187 |
to *get* there, the whole discussion is moot. |
188 |
|
189 |
> > I think that the clique-like nature of many projects is part of the |
190 |
> > problem. We already have too much of a "us versus them" mentality. |
191 |
> |
192 |
> I'm not sure what you mean. Which projects are you speaking about? It |
193 |
> sounds like a silly accusation to me, but perhaps I'm unaware of some |
194 |
> other case. |
195 |
|
196 |
There have been numerous instances of this happening. For quite some |
197 |
time, there was a "Release Engineering versus Hardened" battle. It |
198 |
started before my time, and I have no clue why it existed, but it did. |
199 |
Luckily, both teams have long since worked through such problems and now |
200 |
happily cooperate, but it wasn't always that way. |
201 |
|
202 |
> > How will moving to having lots of independent projects with no central |
203 |
> > authority make Gentoo better? |
204 |
> |
205 |
> I have said this in the proposal. If you don't agree on specific points, |
206 |
> please provide arguments to back up your position. |
207 |
|
208 |
The specific point I'm arguing, then, is your assumption that making |
209 |
these changes will make anything better. I don't think you've shown |
210 |
enough proof that anything will improve by making the changes you've |
211 |
suggested. Because of this, I cannot point out specific instances where |
212 |
I do not agree, since I don't think there's anything to argue against. |
213 |
|
214 |
> > Will it make the distribution better for our users? |
215 |
> |
216 |
> Because gentoo won't be dead in a couple months? Because people will |
217 |
> think again that it's a fun project and want to be part of it? |
218 |
|
219 |
Are you really using rhetoric as an argument? What evidence do you have |
220 |
that Gentoo will be dead in a few months? If you don't have any, you |
221 |
can't exactly use that as a pro-change argument, now can you? Now, had |
222 |
you said something like "We won't be losing developers at a net rate of |
223 |
$x per month" or something else based in fact, I could at least attempt |
224 |
to argue for/against it. However, by arguing solely using conjecture |
225 |
without any facts to back it up, I cannot possibly argue the point. |
226 |
|
227 |
> > Reading back over your proposal with my questions in mind leaves me with |
228 |
> > exactly one last question. |
229 |
> > |
230 |
> > What, exactly, is your proposal supposed to actually accomplish? |
231 |
> |
232 |
> What I *want* to do is to make gentoo fun again. And I believe that |
233 |
> decentralising and giving more autonomy to people will achieve exactly |
234 |
> that, for reasons explained in the proposal. |
235 |
|
236 |
So what you're saying is that your proposal will make things "fun" again |
237 |
by taking what should be global problems, and forcing lots of individual |
238 |
groups to reinvent the wheel and tackle the same problems individually? |
239 |
|
240 |
Where are all of the unofficial projects going to get infrastructure |
241 |
from? Mirror space? |
242 |
|
243 |
Who is going to what is considered "Gentoo" and what isn't? |
244 |
|
245 |
How is this going to improve our image as a cohesive and competitive |
246 |
community-based distribution to our current and potential users? |
247 |
|
248 |
How are we going to ensure that we can even provide a single working |
249 |
product? |
250 |
|
251 |
You haven't answered any of my questions, as far as I can tell. You've |
252 |
simply deflected them or avoided them entirely. Rather than continue |
253 |
with this and turn it into a yet another long thread, that should, by |
254 |
the way, belong somewhere other than a development-related list since |
255 |
this is purely a political change in an attempt to resolve social |
256 |
problems, I'll wait until you've got something much more complete before |
257 |
rendering any further comments or questions. |
258 |
|
259 |
-- |
260 |
Chris Gianelloni |
261 |
Release Engineering Strategic Lead |
262 |
Alpha/AMD64/x86 Architecture Teams |
263 |
Games Developer/Council Member/Foundation Trustee |
264 |
Gentoo Foundation |