Gentoo Archives: gentoo-dev

From: Simon Stelling <blubb@g.o>
To: gentoo-dev@l.g.o
Cc: rphillips@g.o
Subject: Re: [gentoo-dev] Gentoo: State of the Union
Date: Fri, 28 Apr 2006 22:40:52
In Reply to: [gentoo-dev] Gentoo: State of the Union by Ryan Phillips
1 Hi Ryan,
3 Ryan Phillips wrote:
4 > I believe the way Gentoo is doing things is broken. There I have said it. The
5 > entire project has reached a level of being too political and trying to solve
6 > certain problems in the wrong way.
8 I think it actually works quite well. Yes, there is space for
9 improvement, like always, but the situation is at least not bad.
11 > __Problem: Developer Growth__
12 >
13 > I find that developer growth as being a problem. Adding a developer to gentoo
14 > should be as easy as 1. has the user contributed numerous (~5+) patches that
15 > helps the project move forward. If yes, then commit access should be given.
16 > Adding a developer is usually quite a chore. There are numerous reasons why
17 > this is a problem: having a live tree, taking a test, and not defining within
18 > policy when a person could possibly get commit access.
20 I can only speak for me here, but the quiz wasn't a barrier at all to
21 me. Instead, it was an interesting way to make sure that I get familiar
22 with all the stuff I have to. I found it a much better way to answer
23 questions about a topic where you have to find the answers than just
24 reading through tons of docs, not knowing whether something is important
25 to you or completely unrelated.
27 Besides that, I think the tree is far too worthy to give it away after 5
28 patches. Just because I fixed a bunch of compiling errors, that doesn't
29 mean I know how to fix ebuilds. Just because I wrote a few ebuilds, that
30 doesn't mean I understand how eclasses work, which ones to use where and
31 what profile.bashrc is good for.
33 I've seen ebuilds from people who have written quite a bunch of ebuilds
34 and were really interested in understanding how they work, but the work
35 they produced just was awful and hurt my eyes. I don't mean that the
36 mean way, I don't expect anything else, and I was just the same.
37 However, the mentoring process and the quiz have helped me a lot to
38 understand not-so-obvious problems.
40 > All these reasons leave the project stagnant and lacking developers.
42 I wouldn't say so. Just about two weeks or so ago, the recruiters had to
43 defer new requests, because they couldn't deal with them in a timely
44 fashion. You can now tell me that this makes it even worse, but I just
45 see that as the proove of the fact that people are interested in helping
46 us and ready to take the quiz and all the "hassle" involved with
47 becoming a dev.
49 Another good reason to keep the current process is the fact that a lot
50 of people become dev and vanish a week after their mentoring period
51 expired. These people would better contribute to the project in a more
52 distant way IMHO, because it takes up a fair amount of time to clean up
53 these accounts afterwards. If you don't beleave me, ask kloeri. ;)
55 > Perhaps its because of a live tree...
57 That's surely a big factor.
59 > __Problem: Live Tree__
60 >
61 > Having a live tree requires people to be perfect. People are not perfect and
62 > requiring it is ridiculous. I love having commits in my local tree within the
63 > hour, but having a stable and unstable branch makes a lot of sense.
65 It doesn't require people to be perfect. It requires people to think
66 before commiting. If it really required us to be perfect, we wouldn't
67 exist in the first place, would we?
69 Having a stable and unstable branch doesn't have many advantages over
70 stable and unstable keywords IMHO, but requires a HUUUGE effort to keep
71 them in sync. It would make things more complicated than necessary. You
72 say we're lacking developers. Do you really want to spend [insert random
73 big number here] of these much-needed developer hours to merging an old
74 with a new tree?
76 > __Problem: CVS__
78 I would like to see us using svn instead of CVS too, but I think that's
79 just a technical detail, not really fitting here.
81 > __Problem: QA Policies__
83 > Everyone here is on the same team. There will be some breakages in the tree
84 > and those can be dealt with. Like Seemant [1] said, herds are just groups of
85 > like *packages*. The QA Policy is wrong when it says cross-team assistance; we
86 > are all on the *same* team. The tree should naturally work. If it doesn't
87 > then that is a bug for all of us.
89 This sounds romantic. However, Gentoo to me isn't 300 people who are all
90 my friends, all working on a common goal. Gentoo, to me, is a bunch of
91 very nice people that share a goal with me, some big mailing lists with
92 flames every now and then and a big mass of people whose work I use and
93 appreciate but who I don't have a f*cking clue about. I don't know what
94 they are like, they work on other things than I do. But that's not a
95 problem at all.
97 > Conflict resolution should not be a subproject. It should *not* exist at all.
99 You mean conflicts or conflict solution shouldn't exist at all?
100 If the former, that's unrealistic. If the latter, why not?
102 > Rules need to be in place to avoid conflict. Having some sort of voting
103 > structure for all the developers (this doesn't mean requiring everyone to vote)
104 > and not just the council or devrel makes a lot of sense for most things. If I
105 > don't like how someone is acting within the project there should be a vote and
106 > then see if that person is kicked out. No trial, no anything besides a vote.
107 > And if I lose I have to deal with it. Either stay with the project, or find
108 > something else. This solution just works.
110 Do you really think just because 60% of the voting devs agreed on
111 something the other 40% will like it suddenly? Conflicts cannot be
112 avoided, other than shooting down all people which don't share your
113 point of view.
115 > Gentoo should be a fun environment. The previous paragraph should be taken as
116 > a last resort.
118 Gentoo is fun to me.
120 > __Problem: GLEPs__
121 >
122 > I dislike GLEPs. Usually they sit on the website for a long long time not
123 > doing anything. My vote (+1) is get rid of gleps and do everything by email
124 > and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea.
125 > It stifles things from getting done, and there is no ownership of who is going
126 > to implement the idea.
128 I dislike them too. However, you're not addressing the issue IMHO. The
129 problem is not that the council votes on them. The problem is much more
130 that they are proposed to the whole dev community. Yes, you read right.
131 It's mostly a good thing, but it is also a show stopper. I once wrote up
132 a GLEP, sent it to the dev ml. Some people liked it, others wanted this
133 or that changed. I re-submitted it, and they criticised this and that
134 (which is a good thing!). So I fixed all the stuff they pointed out. In
135 the end, I had a GLEP. But what I documented was not the idea I wanted
136 to implement. So I lost interest. The GLEP got approved, but it's still
137 not implemented. I don't know if anybody is working on it, I wont,
138 because it's no longer what I once wanted to push forward.
140 I would like it much more, if the people who are not affected by the
141 GLEP wouldn't read it at all anyway. Whenever something is discussed I'm
142 not involved in or affected by at all, I try to keep my mouth shut. I
143 just trust the guys who submitted it to do their job the right way. And
144 IMHO, this is exactly the point. Trust the others to do their job
145 seriously and well. We don't need a whole dev community voting on an
146 idea. Having everybody vote instead of a 7-headed council won't reduce
147 politicalness. And that was what all your mail was about, in the end.
149 > __Problem: Voting__
151 Heh, really don't need to comment on that one anymore. ;)
153 --
154 Kind Regards,
156 Simon Stelling
157 Gentoo/AMD64 Developer
158 --
159 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Gentoo: State of the Union Ryan Phillips <rphillips@g.o>
Re: [gentoo-dev] Gentoo: State of the Union Daniel Goller <morfic@g.o>