From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32732 invoked from network); 6 Jan 2004 18:58:21 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 6 Jan 2004 18:58:21 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1AdwPE-0005Fo-Mb for arch-gentoo-dev@lists.gentoo.org; Tue, 06 Jan 2004 18:58:20 +0000 Received: (qmail 19779 invoked by uid 50004); 6 Jan 2004 18:55:42 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 24590 invoked from network); 6 Jan 2004 18:55:42 +0000 From: George Shapovalov Organization: Gentoo Linux To: gentoo-dev@lists.gentoo.org Date: Tue, 6 Jan 2004 10:56:08 -0800 User-Agent: KMail/1.5.94 References: <200401052305.45317.robert.cole@support4linux.com> In-Reply-To: <200401052305.45317.robert.cole@support4linux.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401061056.08440.george@gentoo.org> X-Spam-Status: No, hits=0.0 tagged_above=-100000.0 required=5.0 X-Spam-Level: Subject: Re: [gentoo-dev] creating ebuilds X-Archives-Salt: 1641865c-fe55-4573-9181-7b2af7edf8eb X-Archives-Hash: 37e1d194631962abb147d6724c79d46c So, this topic came up again. Well its been a while, more than usual half a year :). Lots have been said about the stalls and the importance of roper maintaince, but I want to chime in on another aspect of this issue - the one that's causing this (and other similar in the past) discussion[s]. On Tuesday 06 January 2004 07:45, Robert Cole wrote: > On Tue January 06 2004 4:44 am, Paul de Vrieze wrote: > > This is certainly not a matter of broken ebuilds or instability it is > > against protection of malice (i.e. criminal behaviour). Besides that > > there must be quality mechanisms in place, but we must protect agains > > criminal behaviour first. > > I personally feel the fewer that have access to cvs the better. I and I > believe Allen are advocating a better middle layer. One that eases the > shoulders of the cvs devs and one that encourages more participation. > Currently it doesn't appear that you can have that participation without > cvs access. I should say I agree with both sides on many points. However the problem is real: We fant to provide maximum flexibility, (that partially means lots of packages) but we want them all be high-quality. Lets face it, Gentoo is triving mostly because of active user involvment, users, who not only [help] fix the bugs and produce new features, but also submit new ebuilds. That's in their nature and I am afraid we cannot separate these things. We cannot say - we want the part of our users that helps us fix the bugs, but we do not want one that's submitting ebuilds :). The roots are deep and psychological, as in what constitutes satisfaction. But I'll leave this topic and go back to the question at hand. Gentoo is growing and we are gonna be faced with larger and larger number of new submissions. So, we can lock the tree and only accept a handfull of new packages now and then. Well, I do not think this will work in the long run: 1. This puts a lot of stress on user-developer relations, and it shows in a regular outbursts of this nature. Plus the locked distro is effectively a dead one - people will start leaving it eventually.. 2. Its too late anyway (actually being like that for a long time already). We are at 100-200 devs (realistically ~100 "maintainers" as there are many doc/infrastructure/other people) but we have 4000+ packages and 7000+ ebuilds (may be even more by now). The ratio is already unhealthy and has been like that for a long time. It did not grow too fast lately because we were stalling somewhat on new submissions, but continuing to do so will increase strain and user unhappiness :(. Another approach: grow the developer base. Not good either - we would have to get like 1000 more devs onboard and, eventually, more close to 10000. Plus, if we would want to match the speed of ebuild submissions (we are taking people in, what I am referring to here is accepting them in "quickly enough") we would not be able to do proper trining. So either forget QA or this will persist for a bit more. But then growing into 10000 arear has a good chances of turning Gentoo into something slow and not very responsive (perhaps other that to the maintained ebuilds needs). So, here I would like to stress the importance of user involvment once again and point out that effectively we do rely on it. I've suggested a possible solution to this dilemma a long time ago (see #1523). It hasn'e been GLEPped yet, because I was (am) bisy with other, "regular" stuff and because this was suggested loong before GLEPs ever came around :). But it will have to if we come to a stage of reall agreement of what we want to do. Plus it has to be reworked a lot since then.. That description is based around the idea of "splitting" the tree (via the means of KEYWORDS for example, but lots have changed since, we might want another way now) into "official" (with its further stable/testing) and "user" areas (considered less stable by portage. This makes these submissions automatically visible and easy to install for those who care, but retains them invisible (and perhaps even unfetchable) for those who dont). While there was support behind it, there was an opposition as well. One real and I think most important objection is along the lines 'do we really want to stress our servers by all these "unsupported" ebuilds?' Nonetheless all is not that bad. We already have a bunch of suggested features implemented. Other parts are still in progress - for example gentoo-stable/stats was up shortly then it ceased to function, but I believe there is an ongoing work on that project "to get it right" this time. portage-ng has tied resources lately as well, but it is necessary in order to provide a way to get all the necessary hooks in.. In short I think it is possible to resolve this problem and build even more versatile system in the end, but this is a lot of work on top of the pending changes to the ongoing projects.. And of course this requires a clear support of the idea in community (and takes a lot of push to actually accomplish things). George -- gentoo-dev@gentoo.org mailing list