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 |