Re: [gentoo-dev] creating ebuilds

[George Shapovalov]

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@g.o mailing list