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 1EuP0i-0005gX-St for garchives@archives.gentoo.org; Thu, 05 Jan 2006 06:54:09 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k056r0Ev023064; Thu, 5 Jan 2006 06:53:00 GMT Received: from cubert.e-centre.net (morbo.e-centre.net [66.154.82.3]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k056oD4k003785 for ; Thu, 5 Jan 2006 06:50:14 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1EuOwv-0006LY-Ge for gentoo-dev@lists.gentoo.org; Thu, 05 Jan 2006 01:50:13 -0500 X-ASG-Debug-ID: 1136443810-12269-201-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-pdx-2.site.stayonline.net (unknown [65.200.64.131]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id 869A5F044E for ; Thu, 5 Jan 2006 01:50:11 -0500 (EST) Received: from nightcrawler ([172.16.1.202]) by et-pdx-2.site.stayonline.net (8.12.6/8.12.6) with ESMTP id k056nr5j015884 for ; Thu, 5 Jan 2006 06:49:53 GMT Date: Wed, 4 Jan 2006 22:49:56 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] Monthly Gentoo Council Reminder for January Subject: Re: [gentoo-dev] Monthly Gentoo Council Reminder for January Message-ID: <20060105064956.GC14338@nightcrawler.e-centre.net> References: <43B96D6D.8080107@gentoo.org> <20060105043130.GI1967@mail.lieber.org> <43BCB0F9.5000505@egr.msu.edu> <200601042205.52361.cshields@gentoo.org> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qbvjkv9qwOGw/5Fx" Content-Disposition: inline In-Reply-To: <200601042205.52361.cshields@gentoo.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.6943 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: afa2d00e-6e7e-4432-be38-06ac8d9bad48 X-Archives-Hash: 4f1b50409d79ea22042f1146d852aa6c --Qbvjkv9qwOGw/5Fx Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 04, 2006 at 10:05:52PM -0800, Corey Shields wrote: > Where is the centralized vision that everyone is working together here th= at=20 > people not directly related to each project will buy in to and therefore = do=20 > 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=20 really didn't do jack for actually acquring folk to work on it, did=20 it (feel free to chime in agaffney since it's effectively yours now a=20 days). > Where is the collaboration between groups=20 > to make it happen? How many projects actually require collaboration amongst multiple=20 groups to pull it off? Yes, if it's infra related we're stuck waiting=20 on you guys to move, but where else is the intricate dependencies=20 between groups y'all seem to be seeing? Don't get me wrong, there *are* dependencies between groups (everyone=20 reliant on toolchain fex). What I'm getting at is that the angle of=20 blaming communication for lack of progress is daft- the issue isn't=20 lack of communication, it's lack of _actual_ work being done. > Portage team is running in one direction,=20 > webapps another, GLI a third direction (while kicking anyone who wishes t= o=20 > run with them in the nuts). Examples would be lovely. > In any structured environment I have worked in,=20 > you have a heirarchy where everyone, down to the grunts, know where they = are=20 > heading as an organization, why they are heading that way, and what they = can=20 > do to help. Even though groups work on differing things, they know how th= ose=20 > things are directly affecting the end goal (mission statement, whatever) > > Right now, Gentoo has it's cliques that come up with their own things, an= d to=20 > get assistance from another clique you're gonna have to have some ties or= =20 > work real hard to sell your idea to them. It's too flat of a model to wo= rk=20 > for any real innovation, else, as Kurt pointed out, we would have seen so= me=20 > 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. >=20 > Gentoo won't fail.. I don't believe that is what Kurt or Lance are sayin= g. I=20 > think the point was that Gentoo is not moving at the typical pace of OSS= =20 > development, and we believe that it is the organizational structure that = is=20 > holding it back. Actually, here's where I'm going to get lynched- (both for bringing up=20 anon* after pissing y'all off by asking about it less then 24 hours=20 previously, and stepping on other toes). Typical foss project is optimized for one thing, and one thing alone-=20 maximal usage of available resources. It has to be *easy* for folks=20 to contribute whatever time they have- this means eliminating as much=20 menial/manual work as possible. Immediate access to most current source so they can raid it and patch=20 it, rather then splitting against an old version, then the maintainer=20 forward porting the patch to head fex is a huge issue. It wastes both=20 the maintainer's time and the random patch submitters time having to=20 juggle between revisions. Further, foss has something of a rapid release cycle. We're actively=20 trying to move in the opposite direction if you consider the actual=20 implication of trying to widen the unstable keywording gap- I'm not=20 stating QA is bad, what I'm stating is that QA explicitly requires=20 delays built in (whether via multiple reviews by devs, or letting the=20 changes sit for a while). End result of it is that it takes longer to get stuff out, with the=20 result waterfalling across the tree- cool nifty package x that has=20 bleeding edge dep y, with dep y sitting due to QA concerns for=20 example. I've not yet actually touched on communication/sync'ing up between=20 volunteers either- that's further delays. For example, you've got=20 crazy/nifty feature X that must be glep'd. You've got realistically a=20 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=20 half a brain aren't going to do work that could be shot down, they're=20 likely going to wait till the proposal is accepted *then* start the=20 work. Probably pissing a selection of people off here (pardon, deal), but=20 the point is that this notion that introducing more communication/sync=20 up points isn't going to accomplish anything. Yes, it's required, but=20 foss is not your typical business work place (thank god). Why has gentoo gotten slower as it's gotten larger? Because the lone=20 wolf developer has less bullshit to deal with, they can just hammer=20 towards their goal. Introduce more folk into it, waste more of their=20 time syncing up with each other, more time of those who see their=20 goal, know how to get their, having to run it past everyone who wants=20 to be know what's afoot. Essentially, the more required sync up/communication built into how=20 things are done, the more bound you are to the slowest folk. Can only=20 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? >=20 > Thanks for your comments.. As for management, anyone who reads "Five=20 > Dysfunctions of a Team" by Patrick Lencioni[1] will see all of the proble= ms=20 > 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=20 good is fundamentally the issue here- more process tagged into gentoo=20 isn't going to help anything, just push us further towards=20 debianization (something that's bugged me for the last 18 months I=20 might add). What I've seen with gentoo is bluntly, wasted resources (bit=20 intentional in some cases). We've been progressing more towards=20 keeping everyone in the loop rather then letting folks spring on ahead=20 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=20 gentoo as a whole to slow down (note the enterprise=20 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=20 point I'm going to make is that pushing for a global solution (whether=20 a BDFL or board or committee) totally is missing the actual issue-=20 that individuals get things done, the larger the # of folks involved=20 in progressing towards something the slower they're going to move. Adding artifical sync ups/communications is a step towards slowing=20 things down further, not speeding things up. Central vision, mission statements, etc, that crap, doesn't=20 actually accomplish anything; if someone is working towards something,=20 someone is working towards it. Extra beuracray/cruft doesn't=20 translate to code however, nor does it really enable faster production=20 of code. ~harring --Qbvjkv9qwOGw/5Fx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvMGUvdBxRoA3VU0RAjZKAKDjIHdcajSrSIVmw2zU+msWx5+FRQCePXPi I25rX/Yp3kEylUU8qZGS5kE= =OX2S -----END PGP SIGNATURE----- --Qbvjkv9qwOGw/5Fx-- -- gentoo-dev@gentoo.org mailing list