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
pgpd01wrJeoHE.pgp
Description: PGP signature
