From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1ExPQK-0000fe-UA for garchives@archives.gentoo.org; Fri, 13 Jan 2006 13:57:01 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k0DDtlVb007939; Fri, 13 Jan 2006 13:55:47 GMT Received: from callisto.cs.kun.nl (callisto.cs.kun.nl [131.174.33.75]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k0DDq3VR019117 for ; Fri, 13 Jan 2006 13:52:03 GMT Received: from localhost (localhost [127.0.0.1]) by callisto.cs.kun.nl (Postfix) with ESMTP id 48B732E8275 for ; Fri, 13 Jan 2006 14:52:28 +0100 (CET) From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Monthly Gentoo Council Reminder for January Date: Fri, 13 Jan 2006 14:52:13 +0100 User-Agent: KMail/1.9 References: <43B96D6D.8080107@gentoo.org> <200601042205.52361.cshields@gentoo.org> <20060105064956.GC14338@nightcrawler.e-centre.net> In-Reply-To: <20060105064956.GC14338@nightcrawler.e-centre.net> X-Face: #Lb+'V@sGJ;ptgo5}V"W+5OCoo{LZv;bh,s,`WKLi/J)ed1_$0;6X<=?utf-8?q?700LVV/=3BLqPhiDP=5E=0A=09=27f=5Dfnv?=@%6M8\'HR1t=aFx;ePfp{ZQoBe+e)JOQ8T5*(_;mHY+cltLGq<;@$Y,=?utf-8?q?O=5C=24=0A=09Tm=23G6M?=,g![Q62J{na*S9d;R[^8pc%u\aiLqU@`kJtYl"^6pxdW Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2435758.0v591bUOUv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601131452.25011.pauldv@gentoo.org> X-Archives-Salt: 624f9af3-2863-4a6f-9e11-b537bd13f821 X-Archives-Hash: 793743a0f92e2a1ea7b62acd34fdf635 --nextPart2435758.0v591bUOUv Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 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=20 prospective improvement projects. This stuff however stands and falls=20 with people being willing to do the work. While I have been instrumental=20 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=20 that this is wrong, or unnatural. It is something that could be expected.=20 A group of 300 people is not similar to a team of 40. The big amount of=20 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=20 didn't work. Open source organizations are different from normal ones=20 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=20 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=20 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=20 less packages. And the fact that we had Daniel, who often just said "Yes"=20 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= =20 project down. It means create subproject that at some point takes a=20 snapshot of the distribution and makes a stable fork from that that only=20 changes for security issues. It should not limit the progress of the=20 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.=20 Once for each developer. Good luck, I'll put my money on an approach that=20 looks at all developers at once. To try to solve things for all (probably=20 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=20 nature. Of course packages get updated, some new features get added to=20 portage, and things improve a bit gradually. However in general the idea=20 is that the gentoo distribution 1 year from now is not fundamentally=20 different / improved from the distribution today. This means that others=20 are making innovations and will be getting better than gentoo. I would=20 like to keep gentoo the best distribution (for me) around, and as such=20 would like gentoo to be more innovative. There are currently some issues that limit this innovation. First of all,=20 there is currently no overall vision of where gentoo will be in say 2=20 years. Second, we lack leadership. The council is there to make=20 decisions, as was the management team before. The council is intended to=20 be an improvement to the non-functioning hierarchy of projects. The=20 council should however not be a limiting factor to the improvement of=20 gentoo. If we take that reducing the number of developers to 30 is not going to be= =20 the solution, we need to find another solution to improve innovation in=20 gentoo. Part of that is in infrastructure, like project overlays that=20 allow for testing out stuff. Another part is in the organization of=20 gentoo. Innovation should be encouraged, while effort should also not go=20 wasted on dead projects. Perhaps a single lead would be a way to=20 encourage innovation, perhaps not. If enough people think it will, we=20 might want to try it out. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart2435758.0v591bUOUv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDx7CYbKx5DBjWFdsRAkVdAJ0dOU4DLKRZMigsYMHgVh0b34SOtgCdEIvV eda+CZd1qY90PshdOY8aXSM= =zJqp -----END PGP SIGNATURE----- --nextPart2435758.0v591bUOUv-- -- gentoo-dev@gentoo.org mailing list