Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Brian Harring]

On Wed, Jan 04, 2006 at 10:05:52PM -0800, Corey Shields wrote:
> Where is the centralized vision that everyone is working together here that
> people not directly related to each project will buy in to and therefore do
> what they can to see it succeed?

We've had centralized visions for a long while.  Recall use/slot deps?

See them available anywhere?

Vision ofr an installer?  Yes, underway now, but the centralized vision 
really didn't do jack for actually acquring folk to work on it, did 
it (feel free to chime in agaffney since it's effectively yours now a 
days).


> Where is the collaboration between groups
> to make it happen?

How many projects actually require collaboration amongst multiple 
groups to pull it off?  Yes, if it's infra related we're stuck waiting 
on you guys to move, but where else is the intricate dependencies 
between groups y'all seem to be seeing?

Don't get me wrong, there *are* dependencies between groups (everyone 
reliant on toolchain fex).  What I'm getting at is that the angle of 
blaming communication for lack of progress is daft- the issue isn't 
lack of communication, it's lack of _actual_ work being done.


> Portage team is running in one direction,
> webapps another, GLI a third direction (while kicking anyone who wishes to
> run with them in the nuts).

Examples would be lovely.


> In any structured environment I have worked in,
> you have a heirarchy where everyone, down to the grunts, know where they are
> heading as an organization, why they are heading that way, and what they can
> do to help. Even though groups work on differing things, they know how those
> things are directly affecting the end goal (mission statement, whatever)
>
> Right now, Gentoo has it's cliques that come up with their own things, and to
> get assistance from another clique you're gonna have to have some ties or
> work real hard to sell your idea to them.  It's too flat of a model to work
> for any real innovation, else, as Kurt pointed out, we would have seen some
> cool stuff in the past couple of years.
>
> > If this Gentoo project fails/falters (like you seem to think it is
> > heading) you are free to do the same, form your own project with it's
> > own set of rules and leader if you so choose.
>
> Gentoo won't fail..  I don't believe that is what Kurt or Lance are saying.  I
> think the point was that Gentoo is not moving at the typical pace of OSS
> development, and we believe that it is the organizational structure that is
> holding it back.

Actually, here's where I'm going to get lynched- (both for bringing up 
anon* after pissing y'all off by asking about it less then 24 hours 
previously, and stepping on other toes).

Typical foss project is optimized for one thing, and one thing alone- 
maximal usage of available resources.  It has to be *easy* for folks 
to contribute whatever time they have- this means eliminating as much 
menial/manual work as possible.

Immediate access to most current source so they can raid it and patch 
it, rather then splitting against an old version, then the maintainer 
forward porting the patch to head fex is a huge issue.  It wastes both 
the maintainer's time and the random patch submitters time having to 
juggle between revisions.

Further, foss has something of a rapid release cycle.  We're actively 
trying to move in the opposite direction if you consider the actual 
implication of trying to widen the unstable keywording gap- I'm not 
stating QA is bad, what I'm stating is that QA explicitly requires 
delays built in (whether via multiple reviews by devs, or letting the 
changes sit for a while).

End result of it is that it takes longer to get stuff out, with the 
result waterfalling across the tree- cool nifty package x that has 
bleeding edge dep y, with dep y sitting due to QA concerns for 
example.

I've not yet actually touched on communication/sync'ing up between 
volunteers either- that's further delays.  For example, you've got 
crazy/nifty feature X that must be glep'd.  You've got realistically a 
wait of a month before it's worth starting the actual work for it.

Yes, a month.  Reason being that glep can be ixnayed, thus those with 
half a brain aren't going to do work that could be shot down, they're 
likely going to wait till the proposal is accepted *then* start the 
work.

Probably pissing a selection of people off here (pardon, deal), but 
the point is that this notion that introducing more communication/sync 
up points isn't going to accomplish anything.  Yes, it's required, but 
foss is not your typical business work place (thank god).

Why has gentoo gotten slower as it's gotten larger?  Because the lone 
wolf developer has less bullshit to deal with, they can just hammer 
towards their goal.  Introduce more folk into it, waste more of their 
time syncing up with each other, more time of those who see their 
goal, know how to get their, having to run it past everyone who wants 
to be know what's afoot.

Essentially, the more required sync up/communication built into how 
things are done, the more bound you are to the slowest folk.  Can only 
run go as fast as your slowest member effectively.


> > Partially I ( as currently still a user at this point ) would like to
> > see a bit more project management.  I see that webapps posted a monthly
> > meeting reminder to -dev, but how many projects really have meetings
> > that often?  Do they accomplish anything?  Should we have someone that
> > tries to attend most meetings to make sure things are going smoothly, or
> > going at all?  Do we need to have slacking projects that get killed off
> > by the council as well as "slacker" council members?
>
> Thanks for your comments..   As for management, anyone who reads "Five
> Dysfunctions of a Team" by Patrick Lencioni[1] will see all of the problems
> that Gentoo has, as well as the potential Gentoo has if it worked well.

Not trying to stick it to you, but I think what you're pointing at as 
good is fundamentally the issue here- more process tagged into gentoo 
isn't going to help anything, just push us further towards 
debianization (something that's bugged me for the last 18 months I 
might add).

What I've seen with gentoo is bluntly, wasted resources (bit 
intentional in some cases).  We've been progressing more towards 
keeping everyone in the loop rather then letting folks spring on ahead 
and get things done (sometimes with a bit of a mess in the process).

Note I said 'intentional'; seems like people have been pushing for 
gentoo as a whole to slow down (note the enterprise 
concerns/complaints that hit the ml every 6 months for example).

Dunno.  Maybe it's all a ramble, maybe you think I'm a loon, but final 
point I'm going to make is that pushing for a global solution (whether 
a BDFL or board or committee) totally is missing the actual issue- 
that individuals get things done, the larger the # of folks involved 
in progressing towards something the slower they're going to move.

Adding artifical sync ups/communications is a step towards slowing 
things down further, not speeding things up.

Central vision, mission statements, etc, that crap, doesn't 
actually accomplish anything; if someone is working towards something, 
someone is working towards it.  Extra beuracray/cruft doesn't 
translate to code however, nor does it really enable faster production 
of code.

~harring