1 |
On Thursday 05 January 2006 07:49, Brian Harring wrote: |
2 |
> On Wed, Jan 04, 2006 at 10:05:52PM -0800, Corey Shields wrote: |
3 |
> > Where is the centralized vision that everyone is working together |
4 |
> > here that people not directly related to each project will buy in to |
5 |
> > and therefore do what they can to see it succeed? |
6 |
> |
7 |
> We've had centralized visions for a long while. Recall use/slot deps? |
8 |
> |
9 |
> See them available anywhere? |
10 |
|
11 |
Those requirements have been there since before 1.0. When the team was |
12 |
still smaller. |
13 |
|
14 |
> |
15 |
> Vision ofr an installer? Yes, underway now, but the centralized vision |
16 |
> really didn't do jack for actually acquring folk to work on it, did |
17 |
> it (feel free to chime in agaffney since it's effectively yours now a |
18 |
> days). |
19 |
|
20 |
Actually we put a lot of effort into starting it off, along with other |
21 |
prospective improvement projects. This stuff however stands and falls |
22 |
with people being willing to do the work. While I have been instrumental |
23 |
in starting it up, I never had time to do the work myself. |
24 |
|
25 |
> > Portage team is running in one direction, |
26 |
> > webapps another, GLI a third direction (while kicking anyone who |
27 |
> > wishes to run with them in the nuts). |
28 |
> |
29 |
> Examples would be lovely. |
30 |
> |
31 |
Look at gentoo-dev@g.o archives for the last years. I'm not saying |
32 |
that this is wrong, or unnatural. It is something that could be expected. |
33 |
A group of 300 people is not similar to a team of 40. The big amount of |
34 |
developers creates subgroups. That includes communication problems. |
35 |
|
36 |
> > Gentoo won't fail.. I don't believe that is what Kurt or Lance are |
37 |
> > saying. I think the point was that Gentoo is not moving at the |
38 |
> > typical pace of OSS development, and we believe that it is the |
39 |
> > organizational structure that is holding it back. |
40 |
> |
41 |
> Actually, here's where I'm going to get lynched- (both for bringing up |
42 |
> anon* after pissing y'all off by asking about it less then 24 hours |
43 |
> previously, and stepping on other toes). |
44 |
|
45 |
Organizational structure doesn't mean bureaucracy. We already saw that |
46 |
didn't work. Open source organizations are different from normal ones |
47 |
though. This includes chronic lack of time for many participants. |
48 |
|
49 |
> Typical foss project is optimized for one thing, and one thing alone- |
50 |
> maximal usage of available resources. It has to be *easy* for folks |
51 |
> to contribute whatever time they have- this means eliminating as much |
52 |
> menial/manual work as possible. |
53 |
|
54 |
Gentoo is not a typical OSS project either. Developing a distribution is |
55 |
fundamentally different from developing one application. |
56 |
|
57 |
> Further, foss has something of a rapid release cycle. We're actively |
58 |
> trying to move in the opposite direction if you consider the actual |
59 |
> implication of trying to widen the unstable keywording gap- I'm not |
60 |
> stating QA is bad, what I'm stating is that QA explicitly requires |
61 |
> delays built in (whether via multiple reviews by devs, or letting the |
62 |
> changes sit for a while). |
63 |
|
64 |
We try to make a better gentoo. This does not mean do what every other |
65 |
foss project does. No matter how applicable. |
66 |
|
67 |
> Why has gentoo gotten slower as it's gotten larger? Because the lone |
68 |
> wolf developer has less bullshit to deal with, they can just hammer |
69 |
> towards their goal. Introduce more folk into it, waste more of their |
70 |
> time syncing up with each other, more time of those who see their |
71 |
> goal, know how to get their, having to run it past everyone who wants |
72 |
> to be know what's afoot. |
73 |
|
74 |
Also remember the lack of stability at that time. And the fact there were |
75 |
less packages. And the fact that we had Daniel, who often just said "Yes" |
76 |
or "No", shortcutting any decision. |
77 |
|
78 |
> > Thanks for your comments.. As for management, anyone who reads |
79 |
> > "Five Dysfunctions of a Team" by Patrick Lencioni[1] will see all of |
80 |
> > the problems that Gentoo has, as well as the potential Gentoo has if |
81 |
> > it worked well. |
82 |
> |
83 |
> Not trying to stick it to you, but I think what you're pointing at as |
84 |
> good is fundamentally the issue here- more process tagged into gentoo |
85 |
> isn't going to help anything, just push us further towards |
86 |
> debianization (something that's bugged me for the last 18 months I |
87 |
> might add). |
88 |
|
89 |
What I think people are arguing about is how to prevent this. |
90 |
|
91 |
> |
92 |
> What I've seen with gentoo is bluntly, wasted resources (bit |
93 |
> intentional in some cases). We've been progressing more towards |
94 |
> keeping everyone in the loop rather then letting folks spring on ahead |
95 |
> and get things done (sometimes with a bit of a mess in the process). |
96 |
> |
97 |
> Note I said 'intentional'; seems like people have been pushing for |
98 |
> gentoo as a whole to slow down (note the enterprise |
99 |
> concerns/complaints that hit the ml every 6 months for example). |
100 |
|
101 |
There you've got it wrong in my opinion. Enterprise does not mean slow the |
102 |
project down. It means create subproject that at some point takes a |
103 |
snapshot of the distribution and makes a stable fork from that that only |
104 |
changes for security issues. It should not limit the progress of the |
105 |
project itself. |
106 |
|
107 |
> Dunno. Maybe it's all a ramble, maybe you think I'm a loon, but final |
108 |
> point I'm going to make is that pushing for a global solution (whether |
109 |
> a BDFL or board or committee) totally is missing the actual issue- |
110 |
> that individuals get things done, the larger the # of folks involved |
111 |
> in progressing towards something the slower they're going to move. |
112 |
|
113 |
So you want to solve the problem of making gentoo go forward 300 times. |
114 |
Once for each developer. Good luck, I'll put my money on an approach that |
115 |
looks at all developers at once. To try to solve things for all (probably |
116 |
not once ;-) ) |
117 |
|
118 |
> Central vision, mission statements, etc, that crap, doesn't |
119 |
> actually accomplish anything; if someone is working towards something, |
120 |
> someone is working towards it. Extra beuracray/cruft doesn't |
121 |
> translate to code however, nor does it really enable faster production |
122 |
> of code. |
123 |
|
124 |
What I see as the problem is that gentoo has become quite stable in |
125 |
nature. Of course packages get updated, some new features get added to |
126 |
portage, and things improve a bit gradually. However in general the idea |
127 |
is that the gentoo distribution 1 year from now is not fundamentally |
128 |
different / improved from the distribution today. This means that others |
129 |
are making innovations and will be getting better than gentoo. I would |
130 |
like to keep gentoo the best distribution (for me) around, and as such |
131 |
would like gentoo to be more innovative. |
132 |
|
133 |
There are currently some issues that limit this innovation. First of all, |
134 |
there is currently no overall vision of where gentoo will be in say 2 |
135 |
years. Second, we lack leadership. The council is there to make |
136 |
decisions, as was the management team before. The council is intended to |
137 |
be an improvement to the non-functioning hierarchy of projects. The |
138 |
council should however not be a limiting factor to the improvement of |
139 |
gentoo. |
140 |
|
141 |
If we take that reducing the number of developers to 30 is not going to be |
142 |
the solution, we need to find another solution to improve innovation in |
143 |
gentoo. Part of that is in infrastructure, like project overlays that |
144 |
allow for testing out stuff. Another part is in the organization of |
145 |
gentoo. Innovation should be encouraged, while effort should also not go |
146 |
wasted on dead projects. Perhaps a single lead would be a way to |
147 |
encourage innovation, perhaps not. If enough people think it will, we |
148 |
might want to try it out. |
149 |
|
150 |
Paul |
151 |
|
152 |
-- |
153 |
Paul de Vrieze |
154 |
Gentoo Developer |
155 |
Mail: pauldv@g.o |
156 |
Homepage: http://www.devrieze.net |