Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] New metastructure proposal
Date: Wed, 11 Apr 2007 14:54:49
Message-Id: 1176303103.8755.38.camel@inertia.twi-31o2.org
In Reply to: Re: [gentoo-dev] [RFC] New metastructure proposal by Alexandre Buisse
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] [RFC] New metastructure proposal Donnie Berkholz <dberkholz@g.o>