Gentoo Archives: gentoo-dev

From: Daniel Goller <morfic@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo: State of the Union
Date: Sat, 29 Apr 2006 01:08:33
Message-Id: 4452BBC2.6080008@gentoo.org
In Reply to: Re: [gentoo-dev] Gentoo: State of the Union by Simon Stelling
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 Simon Stelling wrote:
5 > Hi Ryan,
6 >
7 > Ryan Phillips wrote:
8 >> I believe the way Gentoo is doing things is broken. There I have said
9 >> it. The
10 >> entire project has reached a level of being too political and trying
11 >> to solve
12 >> certain problems in the wrong way.
13 >
14 > I think it actually works quite well. Yes, there is space for
15 > improvement, like always, but the situation is at least not bad.
16
17 how do you call it then if the entities in place make a decision, after
18 some long winded strange tribunal, and when they made a decision, people
19 ask "hey where is my vote?", i am not after devrel, what i am saying is,
20 noone appreciates their work it seems, so why couldn't they leave the
21 decision making to a developer vote, with the saved time, they could go
22 on and do something they enjoy/have fun with (those of you in devrel who
23 enjoy your devrel work (wrt to conflict resolution) i am glad you do, i
24 just don't think many at devrel enjoy hearing they are wrong no matter
25 how they decide)
26 the people affected by the vote could accept a developer vote much
27 easier than a devrel decision
28
29 >
30 >> __Problem: Developer Growth__
31 >>
32 >> I find that developer growth as being a problem. Adding a developer
33 >> to gentoo
34 >> should be as easy as 1. has the user contributed numerous (~5+)
35 >> patches that
36 >> helps the project move forward. If yes, then commit access should be
37 >> given.
38 >> Adding a developer is usually quite a chore. There are numerous
39 >> reasons why
40 >> this is a problem: having a live tree, taking a test, and not defining
41 >> within
42 >> policy when a person could possibly get commit access.
43 >
44 > I can only speak for me here, but the quiz wasn't a barrier at all to
45 > me. Instead, it was an interesting way to make sure that I get familiar
46 > with all the stuff I have to. I found it a much better way to answer
47 > questions about a topic where you have to find the answers than just
48 > reading through tons of docs, not knowing whether something is important
49 > to you or completely unrelated.
50 >
51 and we also have lost developers that projects were eager to get on the
52 team, from what i recall over the developer questioning why an official
53 quiz must be answered by finding things in unofficial docs in dev spaces
54 no, that is not hard, but the question was valid, and with the whole
55 process allowing all of gentoo to make this possible or not, a developer
56 should be put in place by the leads of that project, at the project
57 leads discretion, they know the people they plan on hiring much better
58 than we know most people in our AT program, ATs have been turned into
59 devs after a very short time, the quiz is a silly hurdle if it gages
60 your ability to google, not your ability to write ebuilds
61
62 > Besides that, I think the tree is far too worthy to give it away after 5
63 > patches. Just because I fixed a bunch of compiling errors, that doesn't
64 > mean I know how to fix ebuilds. Just because I wrote a few ebuilds, that
65 > doesn't mean I understand how eclasses work, which ones to use where and
66 > what profile.bashrc is good for.
67
68 we are too possessive, if you give out access to a non-live tree, and
69 you see the commits were not fit for merging, and the person in question
70 does not learn from advise given, the person does not have to keep
71 commit access, but it would be nice to be more inviting than to keep our
72 high and mighty attitude, we are not so different from our users, many
73 of which are far better than we are, we just passed some strange test
74 you can pass by cut& paste or paraphrasing from the right docs, you can
75 do that w/o even knowing what you talk about
76
77 >
78 > I've seen ebuilds from people who have written quite a bunch of ebuilds
79 > and were really interested in understanding how they work, but the work
80 > they produced just was awful and hurt my eyes. I don't mean that the
81 > mean way, I don't expect anything else, and I was just the same.
82 > However, the mentoring process and the quiz have helped me a lot to
83 > understand not-so-obvious problems.
84 >
85
86 who stops you from fixing something here and there before you merge it,
87 you seem to think having a non live tree would unbind us from our
88 responsibility to help them become better
89
90 what a non live tree with commits by new people would allow is that
91 teams could check what there is to merge and say "great wrk, i merge
92 that" instead of just that one developer who works with that user, he
93 will be easier part of the family, a team member could approach him and
94 tell him, i merged it after quoting all your paths, please do so next
95 time, and peope still learn
96
97 if you think passing a test makes you a good driver, then think again,
98 it is constant learning and evolvement that makes you a good driver, and
99 we give out licenses quite easy, then if you are not suited, bye bye license
100
101 >> All these reasons leave the project stagnant and lacking developers.
102 >
103 > I wouldn't say so. Just about two weeks or so ago, the recruiters had to
104 > defer new requests, because they couldn't deal with them in a timely
105 > fashion. You can now tell me that this makes it even worse, but I just
106 > see that as the proove of the fact that people are interested in helping
107 > us and ready to take the quiz and all the "hassle" involved with
108 > becoming a dev.
109 >
110 > Another good reason to keep the current process is the fact that a lot
111 > of people become dev and vanish a week after their mentoring period
112 > expired. These people would better contribute to the project in a more
113 > distant way IMHO, because it takes up a fair amount of time to clean up
114 > these accounts afterwards. If you don't beleave me, ask kloeri. ;)
115 >
116
117 read what you wrote closely, you describe how well things work
118 currently...i think not, they are overworked due to how involved their
119 part of the process is, not because they have 300 new devs to process.
120 the hassle is not big, it just delays things, and prooves nothing
121 i can mentor someone and later on end up asking him for advise, because
122 i saw his abilities and know he is good...better than me when it comes
123 to technical issues, him passing the quiz did not tell me that, and
124 neither does it tell you anything, seeing his work tells me and you
125 something, so let their people's work speak for them, not the passing of
126 quizes
127
128 >> Perhaps its because of a live tree...
129 >
130 > That's surely a big factor.
131
132 indeed it is, glad people do agree :)
133 >
134 >> __Problem: Live Tree__
135 >>
136 >> Having a live tree requires people to be perfect. People are not
137 >> perfect and
138 >> requiring it is ridiculous. I love having commits in my local tree
139 >> within the
140 >> hour, but having a stable and unstable branch makes a lot of sense.
141 >
142 > It doesn't require people to be perfect. It requires people to think
143 > before commiting. If it really required us to be perfect, we wouldn't
144 > exist in the first place, would we?
145 >
146 i don't know how perfection threatens our existence...so yeah it
147 requires many dedicated perfect gentoo users (that's what we are, gentoo
148 users with @gentoo.org email addresses and commit access to a live tree)
149 to make things go smooth, and it could go smoother if we had more
150 people, in more timezones, in more countries, in more states, you can
151 never have to many people, not many have full 56 hours/wk for gentoo, so
152 every 1hr per day can make a difference
153
154 > Having a stable and unstable branch doesn't have many advantages over
155 > stable and unstable keywords IMHO, but requires a HUUUGE effort to keep
156 > them in sync. It would make things more complicated than necessary. You
157 > say we're lacking developers. Do you really want to spend [insert random
158 > big number here] of these much-needed developer hours to merging an old
159 > with a new tree?
160 >
161
162 you don't have to merge the whole tree at once, each project has
163 developers who work on packages of the herds they maintain, the
164 Changelog will tell you why there is a change, if it matters to you, you
165 verify and commit, but the nitty gritty of fixing it is long done
166
167 >> __Problem: CVS__
168 >
169 > I would like to see us using svn instead of CVS too, but I think that's
170 > just a technical detail, not really fitting here.
171 >
172 well, if cvs keeps us from going to a non-live tree, then it does
173 pertain to the discussion at hand, just if it should be svn or
174 [insertfavoritescmhere] is another point (that could quickly be solved
175 with a better voting structure, give the power back to the people,
176 simplify things, and then get this issue resolved with a vote)
177
178 >> __Problem: QA Policies__
179 >
180 >> Everyone here is on the same team. There will be some breakages in
181 >> the tree
182 >> and those can be dealt with. Like Seemant [1] said, herds are just
183 >> groups of
184 >> like *packages*. The QA Policy is wrong when it says cross-team
185 >> assistance; we
186 >> are all on the *same* team. The tree should naturally work. If it
187 >> doesn't
188 >> then that is a bug for all of us.
189 >
190 > This sounds romantic. However, Gentoo to me isn't 300 people who are all
191 > my friends, all working on a common goal. Gentoo, to me, is a bunch of
192 > very nice people that share a goal with me, some big mailing lists with
193 > flames every now and then and a big mass of people whose work I use and
194 > appreciate but who I don't have a f*cking clue about. I don't know what
195 > they are like, they work on other things than I do. But that's not a
196 > problem at all.
197 >
198 rather than having a QA policy that deals with punishment of devs, we
199 should focus on a system where an accidental commit has less impact, if
200 someone makes a commit in another branch, another set of eyes will have
201 a chance to catch it instead of things being in everyone's --sync in ~2
202 hours, a QA team could still scan the tree for things, but since they
203 find problems in the branches rather than the live tree will not have to
204 worry about what they do until the issue with the unruly dev is
205 resolved, and if the issues are indeed of magnitude, they can go and ask
206 for a developer removal vote, if someone seconds that proposal, all
207 developers can vote, and if the devs who vote think the problem is big
208 and sizable enough, they can vote +1 for his removal, 0 to abstain or -1
209 if they disagree with the measure asked for by QA
210
211 >> Conflict resolution should not be a subproject. It should *not* exist
212 >> at all.
213 >
214 > You mean conflicts or conflict solution shouldn't exist at all?
215 > If the former, that's unrealistic. If the latter, why not?
216 >
217
218 we shouldn't have an underappreciated overworked entity (not intending
219 to upset the members of said entity, i know there are people behind the
220 alias) that makes the decisions we ask them to make to hear that they
221 did it wrong again (i am sure it gets tiring to hear us say that over
222 and over), instead the developers bring up the issue, if someone seconds
223 that, people vote and the issue gets resolved, one way or another
224 now if the technical issue is brought up by a project lead and does not
225 affect gentoo as a whole, then that project should vote, not all of us
226 who are not affected, if we like it or not
227
228 >> Rules need to be in place to avoid conflict. Having some sort of voting
229 >> structure for all the developers (this doesn't mean requiring everyone
230 >> to vote)
231 >> and not just the council or devrel makes a lot of sense for most
232 >> things. If I
233 >> don't like how someone is acting within the project there should be a
234 >> vote and
235 >> then see if that person is kicked out. No trial, no anything besides
236 >> a vote.
237 >> And if I lose I have to deal with it. Either stay with the project,
238 >> or find
239 >> something else. This solution just works.
240 >
241 > Do you really think just because 60% of the voting devs agreed on
242 > something the other 40% will like it suddenly? Conflicts cannot be
243 > avoided, other than shooting down all people which don't share your
244 > point of view.
245 >
246
247 in what world do you live in where 100% of members like decisions the
248 group makes? cause i wanna go move there.
249 be realistic. having a majority is enough, you could discuss if needing
250 a simple or super majority based on what is voted on
251
252 did anyone read the policies Ryan linked to (in particular the voting one?)
253
254 >> Gentoo should be a fun environment. The previous paragraph should be
255 >> taken as
256 >> a last resort.
257 >
258 > Gentoo is fun to me.
259 >
260 gentoo is too political, to too distanced from the developers (on a
261 decision making basis i mean) to have it be fun, our elitism drives
262 prospects away, when we should embrace them and use our good judgement
263 to decide if someone should have commit access, (for one of our projects
264 to lose a good guy over the rest of us, who have no say over their
265 project, bitching and moaning when our dev quiz gets criticized is
266 wrongi should be left to that project to decide if he will work well for
267 them or not), not some synthetic quiz, the quizes get harder and harder,
268 but does kloeri have less and less quick in and out devs to remove?
269
270 >> __Problem: GLEPs__
271 >>
272 >> I dislike GLEPs. Usually they sit on the website for a long long time
273 >> not
274 >> doing anything. My vote (+1) is get rid of gleps and do everything by
275 >> email
276 >> and a vote by the developers. AFAIK, the board votes on the GLEPs.
277 >> Bad Idea.
278 >> It stifles things from getting done, and there is no ownership of who
279 >> is going
280 >> to implement the idea.
281 >
282 > I dislike them too. However, you're not addressing the issue IMHO. The
283 > problem is not that the council votes on them. The problem is much more
284 > that they are proposed to the whole dev community. Yes, you read right.
285 > It's mostly a good thing, but it is also a show stopper. I once wrote up
286 > a GLEP, sent it to the dev ml. Some people liked it, others wanted this
287 > or that changed. I re-submitted it, and they criticised this and that
288 > (which is a good thing!). So I fixed all the stuff they pointed out. In
289 > the end, I had a GLEP. But what I documented was not the idea I wanted
290 > to implement. So I lost interest. The GLEP got approved, but it's still
291 > not implemented. I don't know if anybody is working on it, I wont,
292 > because it's no longer what I once wanted to push forward.
293 >
294 > I would like it much more, if the people who are not affected by the
295 > GLEP wouldn't read it at all anyway. Whenever something is discussed I'm
296 > not involved in or affected by at all, I try to keep my mouth shut. I
297 > just trust the guys who submitted it to do their job the right way. And
298 > IMHO, this is exactly the point. Trust the others to do their job
299 > seriously and well. We don't need a whole dev community voting on an
300 > idea. Having everybody vote instead of a 7-headed council won't reduce
301 > politicalness. And that was what all your mail was about, in the end.
302 >
303
304 i talked about that further up, if the idea only affects your team,
305 bring it up to your team lead for a vote, if gets seconded, your team
306 votes, not us who have an opinion about your idea, although we do not
307 work on anything that is affected by your idea
308 voting is not limited to all of gentoo voting if it does not affect all
309 of gentoo
310
311 >> __Problem: Voting__
312 >
313 > Heh, really don't need to comment on that one anymore. ;)
314 >
315
316 well i guess i put that one into so many other points i will not
317 reiterate but repost the link i would like to see people comment on,
318 since they happened to vote on this while Ryan wrote this email
319 i provided him with the link since it made us go "OMG! that's it!"
320
321 be fair, nothing i say is final, even if you think i sound like that,
322 those are my ideas, something i would like to see happen
323
324 the link:
325 http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html
326
327 mind you, i would like to discuss a voting policy like it, not smgl,
328 they do their thing, and we do ours, i just think their voting policy
329 kicks our behinds....
330
331 Daniel
332 -----BEGIN PGP SIGNATURE-----
333 Version: GnuPG v1.4.2.1 (GNU/Linux)
334 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
335
336 iD8DBQFEUrvC/aM9DdBw91cRAh/PAKC2pAKFkM6Vp/y8E7LkhlAAkMCYYwCfSdSP
337 HRiQH90C3NwVf49PK9cHckU=
338 =DnLj
339 -----END PGP SIGNATURE-----
340 --
341 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Gentoo: State of the Union "Bryan Ƙstergaard" <kloeri@g.o>