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. |
10 |
|
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... |
14 |
|
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. |
17 |
|
18 |
+1 |
19 |
|
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. |
25 |
|
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. |
30 |
|
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. |
35 |
|
36 |
Yeah, and this is the problem we need to solve to get more corporate |
37 |
adoption. |
38 |
|
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. |
43 |
|
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. |
47 |
|
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. |
54 |
|
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 $$$. |
63 |
|
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. |
72 |
|
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". |
76 |
|
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 :) |
84 |
|
85 |
+1 |
86 |
|
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. |
92 |
|
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] |
96 |
|
97 |
> Gentoo should be a fun environment. I don't see how turning it into a |
98 |
> popularity contest brings back the fun. |
99 |
|
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. |
104 |
|
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. |
112 |
|
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. |
116 |
|
117 |
> I do agree that the GLEP process isn't working. Would we miss it? |
118 |
|
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. |
123 |
|
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. |
128 |
|
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. |
133 |
|
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. |
137 |
|
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... |
141 |
|
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? :) |
150 |
|
151 |
And who's willing to pay the $$$ to help us get there? :) |
152 |
-- |
153 |
gentoo-dev@g.o mailing list |