public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: George Shapovalov <george@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] creating ebuilds
Date: Tue, 6 Jan 2004 10:56:08 -0800	[thread overview]
Message-ID: <200401061056.08440.george@gentoo.org> (raw)
In-Reply-To: <200401052305.45317.robert.cole@support4linux.com>

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


  parent reply	other threads:[~2004-01-06 18:58 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-06  7:05 [gentoo-dev] creating ebuilds Robert Cole
2004-01-06  7:15 ` Jon Portnoy
2004-01-06  7:36   ` Allen Parker
2004-01-06  7:39   ` Robert Cole
2004-01-06  7:55     ` Jon Portnoy
2004-01-06  8:39       ` Robert Cole
2004-01-06  9:54         ` Kurt Lieber
2004-01-06 13:08           ` Caleb Tennis
2004-01-06 14:13             ` Allen Parker
     [not found]             ` <E1Adry1-0003ZV-8m@smtp.gentoo.org>
2004-01-06 21:09               ` Spider
2004-01-07  0:24                 ` Robert Cole
2004-01-07 13:36                   ` Chris Gianelloni
2004-01-06 15:18           ` Robert Cole
2004-01-06 16:04             ` Chris Gianelloni
2004-01-06 16:31               ` Robert Cole
2004-01-06 16:45                 ` Ciaran McCreesh
2004-01-06 17:17                   ` Robert Cole
2004-01-06 19:17                 ` Chris Gianelloni
2004-01-06 19:43                   ` Robert Cole
2004-01-06 20:07                     ` Ciaran McCreesh
2004-01-08  7:12                       ` John Nilsson
2004-01-08  9:56                         ` Paul de Vrieze
2004-01-08 14:36                           ` John Nilsson
2004-01-08 20:53                           ` Nicholas Hockey
2004-01-10 11:39                     ` foser
2004-01-06 12:09         ` Chris Gianelloni
2004-01-06 15:38           ` Robert Cole
2004-01-06 19:29             ` Marius Mauch
2004-01-06 12:44         ` Paul de Vrieze
2004-01-06 15:45           ` Robert Cole
2004-01-06 20:39             ` Paul de Vrieze
2004-01-06 21:11               ` [gentoo-dev] " Eamon Caddigan
2004-01-06 21:37                 ` Caleb Tennis
     [not found]   ` <E1Adllq-0001dV-26@smtp.gentoo.org>
2004-01-06  7:46     ` [gentoo-dev] " Jon Portnoy
     [not found]   ` <E1AdlmM-0001xM-00@deer.gmane.org>
2004-01-07  6:18     ` [gentoo-dev] " Jeff Stuart
2004-01-07 13:20       ` Caleb Tennis
2004-01-06 18:56 ` George Shapovalov [this message]
2004-01-06 19:06   ` [gentoo-dev] " George Shapovalov
2004-01-06 19:45   ` Marius Mauch
2004-01-06 20:44   ` Paul de Vrieze
2004-01-10 11:13   ` foser
2004-01-10 12:16     ` Jason Stubbs
  -- strict thread matches above, loose matches on Subject: below --
2004-01-06  8:17 Robert Cole
2004-01-06 12:57 ` Paul de Vrieze
2004-01-06 15:37 ` Seemant Kulleen
2004-01-06 18:14   ` Robert Cole
2004-01-06 20:49   ` Jan Schubert
     [not found] <E1Adlms-0007w8-Uk@smtp.gentoo.org>
2004-01-06 12:33 ` Paul de Vrieze
2004-01-06 17:26   ` Robert Cole
2004-01-06 17:39     ` Ciaran McCreesh
2004-01-06 18:01       ` Robert Cole
2004-01-06 19:26         ` Chris Gianelloni
2004-01-06 19:53           ` Peter Ruskin
2004-01-06 20:12             ` Ciaran McCreesh
2004-01-06 20:21             ` Marius Mauch
2004-01-06 20:37             ` Jan Schubert
2004-01-06 21:14             ` Chris Gianelloni
2004-01-06 21:36             ` Chris Gianelloni
2004-01-06 19:20     ` Chris Gianelloni
2004-01-06 17:56   ` Eldad Zack
2004-01-06 18:02     ` Eldad Zack
2004-01-06 18:33       ` Robert Cole
2004-01-06 19:31         ` Chris Gianelloni
2004-01-06 20:38       ` Jan Schubert
2004-01-06 20:54       ` Spider
     [not found] <FILESERVERAmEaJswFC00000011@FILESERVER.aurora.local>
2004-01-06 14:57 ` Caleb Tennis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200401061056.08440.george@gentoo.org \
    --to=george@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox