Gentoo Archives: gentoo-dev

From: (Tim Yamin)
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: Sun, 30 Apr 2006 00:02:05
In Reply to: Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip) by Stuart Herbert
1 On Sat, Apr 29, 2006 at 10:33:11PM +0100, Stuart Herbert wrote:
2 > > __Problem: Developer Growth__
3 > >
4 > > Why do people have to take a test?
5 >
6 > There are certain skills we need a developer to demonstrate before we
7 > can give them commit access. There is currently no opportunity for a
8 > would-be-developer to demonstrate all of those skills before they get
9 > commit access.
11 That and the test is standardized: the range of questions it asks
12 people should know the answer to. That's why we have recruiters and
13 don't give out access to anybody...
15 > But I don't see overlays as a replacement for our tests ... they're only
16 > a training ground to help get people ready to take the tests.
18 +1
20 > The magic thing about Gentoo is that everything finds its own level.
21 > That's our secret formula. If an area of working with Linux is
22 > important enough to enough people, Gentoo becomes strong in that area,
23 > and its weaknesses reflect where something simply isn't important enough
24 > for people to make an effort. It's a beautiful thing when it works.
26 That's the beauty of community-based distros -- with a commercial distro
27 you can just wave cash and most of the time, things get done. We can't
28 do that but sooner or later somebody who has the necessary skills to fix
29 the problems starts shouting and problems do get fixed.
31 > It's also the thing that puts a lot of people off. Many people fear
32 > uncertainty. They need to exist within a plan or some sort of structure
33 > in order to be able to function. Our approach is uncertainty in motion.
34 > Your only guarantee is what rsync delivered this morning.
36 Yeah, and this is the problem we need to solve to get more corporate
37 adoption.
39 > The master plan is simply to deliver what $UPSTREAM invents, as close to
40 > what $UPSTREAM intended as possible. That's a different world to what
41 > most people know, and it's a message we do a piss poor job of
42 > communicating to anyone and everyone.
44 Yeah, I think Gentoo's only real PR to users is "Here you go, try it".
45 Those that do soon find out a lot of things "just work" which is exactly
46 what people want.
48 > Splitting up the tree into two - development/testing & arch trees -
49 > would be the sensible thing to do. The counter argument here is that
50 > the arch trees would wither and die, because all the fun would be
51 > happening in the other trees. I don't buy that for an instant. Simply
52 > make the arch trees the default on the install media, and 80% of the
53 > userbase will never even notice that the other tree even exists.
55 I don't think this will work. Your major problem is going to be merging
56 changes from users working on the arch trees to the dev trees and vice-
57 versa... users would (unknowingly) work on the arch trees (possibly on
58 some pretty serious changes) and then be told none of them apply any
59 longer. The advantage of one tree is that development is streamlined and
60 is always going in one direction - forward. With large branching this is
61 still doable. But it needs time and more importantly people and also the
62 motivation to do the job. And that usually means $$$.
64 > Those behind that proposal mean well, but I personally feel that their
65 > focus isn't where it will do the most good. The proposals that Mark has
66 > posted on -dev are for a reactive, enforcement-first team that's focused
67 > on applying coding standards across all our packages. A proactive,
68 > education-led team that's focused on finding out what's actually hurting
69 > our users will deliver more benefit to Gentoo in a shorter period of
70 > time. Give a man a fish, and you feed him for a day. Teach him how to
71 > fish, and you feed him for a lifetime. It's not hokum.
73 I think that's the underlying idea -- if developers aren't up to scratch
74 the QA team would notice this pretty quickly and "teach the man how to
75 fish" the "proper way".
77 > Man is a political animal, and this sort of voting structure I find too
78 > simplistic and too naive. How does it cope with the malicious dev who
79 > takes every opportunity to slander another one behind their back? If
80 > you tell someone something often enough, people accept it as the truth -
81 > even if it's a lie. And people are lazy. They'll take information from
82 > someone they trust, and not take the trouble to learn whether or not
83 > that information is true. That's why advertising works :)
85 +1
87 > In any walk of life, it's a sad but true fact that most of the staff in
88 > most organisations do not "get" what the organisation is, and what its
89 > culture is, to the extent that they can be trusted to preserve it
90 > without assistance. Every one of us has a unique perspective on the
91 > world, and no two of us have an identical perspective.
93 In one aspect that's what makes Gentoo work. Somebody comes along with
94 a product/idea and somebody else comes along with "can I make it flexible
95 enough to also do X, Y and Z?" [Look at catalyst, for example]
97 > Gentoo should be a fun environment. I don't see how turning it into a
98 > popularity contest brings back the fun.
100 +1. Things generally do need a management structure. I think the one we
101 have now isn't perfect, but for the most part, it works. It's usually
102 clear what needs to be done and who you need to speak to get an issue
103 or proposal moving forward.
105 > > __Problem: GLEPs__
106 > >
107 > > I dislike GLEPs. Usually they sit on the website for a long long time not
108 > > doing anything. My vote (+1) is get rid of gleps and do everything by email
109 > > and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea.
110 > > It stifles things from getting done, and there is no ownership of who is going
111 > > to implement the idea.
113 Sure, and take a whole month or two for a vote. And voting in one or two
114 days simply doesn't work -- people have a real life and things other than
115 Gentoo to get on with.
117 > I do agree that the GLEP process isn't working. Would we miss it?
119 It's not working. But the ideas are there, and they're getting submitted
120 to a centralized place. Going to the email idea threads will just get
121 lost; at least with a GLEP people know and can very clearly see what
122 has and hasn't been acted on.
124 > In fact, I'd go as far as saying that it's our growth that has become
125 > our problem. Too often we've taken on people because we were grateful
126 > for the extra pair of hands, and haven't taken the time to see whether -
127 > technically and socially - they were right for Gentoo.
129 And too often we've taked on people that commit one or two ebuilds and
130 then disappear. This only makes our problem worse -- they were supposed
131 to help (i.e. clean up somebody else's mess usually) and instead said
132 mess only increases.
134 > But I don't feel that we're in any sort of crisis at the moment. We're
135 > continuing to deliver packages to our users, who are continuing to use
136 > what we produce.
138 Right, and thanks to the bug wranglers properly sorting things it's
139 pretty easy for the motivated person to work on maintainer-needed@
140 bugs...
142 > It's the breakdown in respect between people that's the real issue that
143 > needs addressing. Too many of us only know each other from looking at
144 > pixels on a screen. I think it's time we got off our collective rears,
145 > and did our best to get all of us face to face at the same time.
146 >
147 > I'm offering to lead the effort to establish a global Gentoo developer
148 > conference, and to do whatever it takes to get everything we need to
149 > make this happen. Now who's up for this? :)
151 And who's willing to pay the $$$ to help us get there? :)
152 --
153 gentoo-dev@g.o mailing list