On Thursday 05 January 2006 07:49, Brian Harring wrote: > 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?
Those requirements have been there since before 1.0. When the team was still smaller. > > 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). Actually we put a lot of effort into starting it off, along with other prospective improvement projects. This stuff however stands and falls with people being willing to do the work. While I have been instrumental in starting it up, I never had time to do the work myself. > > 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. > Look at gentoo-dev@gentoo.org archives for the last years. I'm not saying that this is wrong, or unnatural. It is something that could be expected. A group of 300 people is not similar to a team of 40. The big amount of developers creates subgroups. That includes communication problems. > > 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). Organizational structure doesn't mean bureaucracy. We already saw that didn't work. Open source organizations are different from normal ones though. This includes chronic lack of time for many participants. > 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. Gentoo is not a typical OSS project either. Developing a distribution is fundamentally different from developing one application. > 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). We try to make a better gentoo. This does not mean do what every other foss project does. No matter how applicable. > 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. Also remember the lack of stability at that time. And the fact there were less packages. And the fact that we had Daniel, who often just said "Yes" or "No", shortcutting any decision. > > 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 think people are arguing about is how to prevent this. > > 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). There you've got it wrong in my opinion. Enterprise does not mean slow the project down. It means create subproject that at some point takes a snapshot of the distribution and makes a stable fork from that that only changes for security issues. It should not limit the progress of the project itself. > 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. So you want to solve the problem of making gentoo go forward 300 times. Once for each developer. Good luck, I'll put my money on an approach that looks at all developers at once. To try to solve things for all (probably not once ;-) ) > 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. What I see as the problem is that gentoo has become quite stable in nature. Of course packages get updated, some new features get added to portage, and things improve a bit gradually. However in general the idea is that the gentoo distribution 1 year from now is not fundamentally different / improved from the distribution today. This means that others are making innovations and will be getting better than gentoo. I would like to keep gentoo the best distribution (for me) around, and as such would like gentoo to be more innovative. There are currently some issues that limit this innovation. First of all, there is currently no overall vision of where gentoo will be in say 2 years. Second, we lack leadership. The council is there to make decisions, as was the management team before. The council is intended to be an improvement to the non-functioning hierarchy of projects. The council should however not be a limiting factor to the improvement of gentoo. If we take that reducing the number of developers to 30 is not going to be the solution, we need to find another solution to improve innovation in gentoo. Part of that is in infrastructure, like project overlays that allow for testing out stuff. Another part is in the organization of gentoo. Innovation should be encouraged, while effort should also not go wasted on dead projects. Perhaps a single lead would be a way to encourage innovation, perhaps not. If enough people think it will, we might want to try it out. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpzmU4CJk6Ah.pgp
Description: PGP signature
