Gentoo Archives: gentoo-dev

From: Stuart Herbert <stuart@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
Date: Sat, 29 Apr 2006 21:36:17
In Reply to: [gentoo-dev] Gentoo: State of the Union by Ryan Phillips
1 Hi Ryan,
3 I hope you find these comments useful.
5 On Fri, 2006-04-28 at 10:14 -0700, Ryan Phillips wrote:
6 > __Problem: Developer Growth__
7 >
8 > Why do people have to take a test?
10 There are certain skills we need a developer to demonstrate before we
11 can give them commit access. There is currently no opportunity for a
12 would-be-developer to demonstrate all of those skills before they get
13 commit access.
15 This is where working in overlays has helped some groups. It gives
16 would-be-devs an opportunity to learn and develop the skills they would
17 need to become Gentoo developers.
19 But I don't see overlays as a replacement for our tests ... they're only
20 a training ground to help get people ready to take the tests.
22 The magic thing about Gentoo is that everything finds its own level.
23 That's our secret formula. If an area of working with Linux is
24 important enough to enough people, Gentoo becomes strong in that area,
25 and its weaknesses reflect where something simply isn't important enough
26 for people to make an effort. It's a beautiful thing when it works.
28 It's also the thing that puts a lot of people off. Many people fear
29 uncertainty. They need to exist within a plan or some sort of structure
30 in order to be able to function. Our approach is uncertainty in motion.
31 Your only guarantee is what rsync delivered this morning.
33 The master plan is simply to deliver what $UPSTREAM invents, as close to
34 what $UPSTREAM intended as possible. That's a different world to what
35 most people know, and it's a message we do a piss poor job of
36 communicating to anyone and everyone.
38 > __Problem: Live Tree__
39 >
40 > Having a live tree requires people to be perfect. People are not perfect and
41 > requiring it is ridiculous. I love having commits in my local tree within the
42 > hour, but having a stable and unstable branch makes a lot of sense.
44 We have one live tree that is trying to be all things to all people.
45 It's a development tree (package.mask), it's a testing tree (~arch),
46 it's a production tree (one tree per arch). The tree isn't robust or
47 resilient - one mistake intended for the development tree can break the
48 other two trees.
50 Splitting up the tree into two - development/testing & arch trees -
51 would be the sensible thing to do. The counter argument here is that
52 the arch trees would wither and die, because all the fun would be
53 happening in the other trees. I don't buy that for an instant. Simply
54 make the arch trees the default on the install media, and 80% of the
55 userbase will never even notice that the other tree even exists.
57 > __Problem: CVS__
58 >
59 > CVS is one of the worst application ever created.
61 Hear, hear.
63 I'd like to see a move to Subversion made a priority for 2006. If there
64 are problems with Subversion's performance with our tree, engage with
65 its authors to obtain improvements. But get it done.
67 > __Problem: QA Policies__
68 >
69 >
70 >
71 > It seems that the QA Policies are a product of a Live Tree, and going partially
72 > non-live would solve the problems listed.
74 I can see the point, but I don't agree.
76 Those behind that proposal mean well, but I personally feel that their
77 focus isn't where it will do the most good. The proposals that Mark has
78 posted on -dev are for a reactive, enforcement-first team that's focused
79 on applying coding standards across all our packages. A proactive,
80 education-led team that's focused on finding out what's actually hurting
81 our users will deliver more benefit to Gentoo in a shorter period of
82 time. Give a man a fish, and you feed him for a day. Teach him how to
83 fish, and you feed him for a lifetime. It's not hokum.
85 > Conflict resolution should not be a subproject. It should *not* exist at all.
86 > Rules need to be in place to avoid conflict. Having some sort of voting
87 > structure for all the developers (this doesn't mean requiring everyone to vote)
88 > and not just the council or devrel makes a lot of sense for most things. If I
89 > don't like how someone is acting within the project there should be a vote and
90 > then see if that person is kicked out. No trial, no anything besides a vote.
91 > And if I lose I have to deal with it. Either stay with the project, or find
92 > something else. This solution just works.
94 Man is a political animal, and this sort of voting structure I find too
95 simplistic and too naive. How does it cope with the malicious dev who
96 takes every opportunity to slander another one behind their back? If
97 you tell someone something often enough, people accept it as the truth -
98 even if it's a lie. And people are lazy. They'll take information from
99 someone they trust, and not take the trouble to learn whether or not
100 that information is true. That's why advertising works :)
102 In any organisation, you have to have key people who understand what the
103 organisation is about, and who police it to get rid of those people who
104 from the inside are subverting and attacking the organisation's culture.
105 An organisation's culture is it's immune system - it's what keeps things
106 together when everything else is falling apart - and those who undermine
107 it are exceedingly dangerous to the organisation as a whole.
109 In any walk of life, it's a sad but true fact that most of the staff in
110 most organisations do not "get" what the organisation is, and what its
111 culture is, to the extent that they can be trusted to preserve it
112 without assistance. Every one of us has a unique perspective on the
113 world, and no two of us have an identical perspective.
115 > Gentoo should be a fun environment. The previous paragraph should be taken as
116 > a last resort.
118 Gentoo should be a fun environment. I don't see how turning it into a
119 popularity contest brings back the fun.
121 And I don't see how it benefits our users.
123 > __Problem: GLEPs__
124 >
125 > I dislike GLEPs. Usually they sit on the website for a long long time not
126 > doing anything. My vote (+1) is get rid of gleps and do everything by email
127 > and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea.
128 > It stifles things from getting done, and there is no ownership of who is going
129 > to implement the idea.
131 How many of the changes that are covered by the 50 or so GLEPs that
132 exist today have been held up because of the GLEP process? How many of
133 them would have been delivered today under your proposals?
135 I don't think that your argument will stand up to that analysis.
137 I do agree that the GLEP process isn't working. Would we miss it?
139 > __Problem: Voting__
140 >
141 > Gentoo has over 200 developers. People are generally against the voting idea,
142 > but I'm not sure why.
144 I've explained my personal reasons above.
146 > The Apache Foundation has over 1300 developers; they must be doing something
147 > right.
149 I don't see how the size of a workforce is a measurement of success,
150 unless you're a middle manager in a firm who needs an empire underneath
151 you to justify the existance of your own job.
153 In fact, I'd go as far as saying that it's our growth that has become
154 our problem. Too often we've taken on people because we were grateful
155 for the extra pair of hands, and haven't taken the time to see whether -
156 technically and socially - they were right for Gentoo.
158 But I don't feel that we're in any sort of crisis at the moment. We're
159 continuing to deliver packages to our users, who are continuing to use
160 what we produce.
162 We're going through a patch where there are more disputes than some
163 people are comfortable with; but as long as all involved continue to
164 respect each other and to learn from each other, the individual issues
165 will get resolved.
167 It's the breakdown in respect between people that's the real issue that
168 needs addressing. Too many of us only know each other from looking at
169 pixels on a screen. I think it's time we got off our collective rears,
170 and did our best to get all of us face to face at the same time.
172 I'm offering to lead the effort to establish a global Gentoo developer
173 conference, and to do whatever it takes to get everything we need to
174 make this happen. Now who's up for this? :)
176 Best regards,
177 Stu
178 --
179 Stuart Herbert stuart@g.o
180 Gentoo Developer
183 GnuGP key id# F9AFC57C available from
184 Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
185 --


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