From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28188 invoked from network); 10 Jan 2004 11:39:34 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 10 Jan 2004 11:39:34 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1AfHSo-0006cR-3b for arch-gentoo-dev@lists.gentoo.org; Sat, 10 Jan 2004 11:39:34 +0000 Received: (qmail 6760 invoked by uid 50004); 10 Jan 2004 11:39:32 +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 32258 invoked from network); 10 Jan 2004 11:39:32 +0000 From: foser To: gentoo-dev@lists.gentoo.org In-Reply-To: <200401061143.33541.robert.cole@support4linux.com> References: <200401052305.45317.robert.cole@support4linux.com> <200401060831.21756.robert.cole@support4linux.com> <1073416672.8062.29.camel@localhost> <200401061143.33541.robert.cole@support4linux.com> Content-Type: text/plain Message-Id: <1073734755.31672.77.camel@rivendell> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 10 Jan 2004 12:39:15 +0100 Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] creating ebuilds X-Archives-Salt: 53377f21-82de-4d23-b094-bf2124729597 X-Archives-Hash: 910425488eed81fd15ea429daeb77489 On Tue, 2004-01-06 at 20:43, Robert Cole wrote: > On Tue January 06 2004 11:17 am, Chris Gianelloni wrote: > > On Tue, 2004-01-06 at 11:31, Robert Cole wrote: > > > On Tue January 06 2004 8:04 am, Chris Gianelloni wrote: > > > > Someone who is NOT a developer, and therefore not held liable. If I > > > > add a package to the portage tree, I HAVE to maintina it. That is the > > > > current Gentoo policy, and I think a VERY good policy for keeping > > > > poor-quality ebuilds out of the tree. > > > > > > I personally believe this type of management has it's days numbered as > > > gentoo grows. > > > > I respect your opinion, but as far as I can see, Gentoo is sticking with > > the idea that having packages which do not have at least one developer > > willing to maintain it is a bad idea. > > Did I ever say not to have a maintainer? If I did I'm sorry I led you in this > direction. I guess what I'm suggesting is separating dev access and ebuild > contributer access. Ebuild contributer are a class of dev yes but a class in > their own I believe with limited rights to the tree. > Creating this class would give you more maintainers with less overhead for the > cvs-dev class. Adding user submitted ebuilds without proper maintainership has led to a lot of problems which we are currently slowly trying to resolve by the whole herds concept. We try to learn from mistakes in the past here, not doing it all over again. Submitting is much cooler than maintaining i can tell you and your suggestion has no actual maintainership suggestions (although it implies otherwise at the start), so i can't take it very seriously. As someone else said, the ones submitting ebuilds are not always the one wanting to maintain them for as long as it takes. And what i can get from it, cvs-devs should do the maintaining ? Those are the ones that have enough to do as it is. > > No. You do bug reporting when you find something wrong. Quality > > Control is something that is done before a product is shipped to make > > sure it isn't broken. > > That's what ACCEPT_KEYWORDS can be for. Is from what I can tell. You tell wrong, ACCEPT_KEYWORDS certainly isn't suited for the large scale usage you are suggesting and is interpreted the wrong way a lot of times as it is. > No not really. Didn't mean it as that but as you mentioned further down you > can't have it both ways. You can't be an advanced distro using > curring/bleeding edge stuff AND be a rock solid distro. It's just not going > to happen. Well not automatically that is. You can have an extremely stable > gentoo system that pretty darn cutting edge but it takes some effort in > working with masking and make.conf. I do it all the time. It just seems you > want things rock solid stable out the door with gentoo and automatic. That's > not happening at least not now. You can get close without ACCEPT_KEYWORDS > though. Actually Gentoo always promotes itself as a meta-distro, so we can be everything, it just depends on how you want it. We can be both rock stable and cutting-stable-edge, it just depends on the user. > And the addition of ACCEPT_KEYWORDS helped as well but it's meaning and use > seems to be fading away. And this is based on what evidence ? > And you feel with those controls a dev will be restricted? I don't think so it > would just be an extra layer they would have to go through or ask to be setup > perm with the access to the new area. They would have to think before acting. That is a non-argument, devs should think before taking action at all times. Restricting access won't help there. The only reason for different access levels i can see is security concerns, but i actually like it open as it is and the inter-dev trust that it implies. > > You're speaking out of both sides of your mouth. On one side you want > > to make adding ebuilds quicker, and on the other, you want us to > > implement measures to slow developer's abilities to work. Which is it? > > I would like to see fine grain controls and a different group of devs like > cvs-dev and ebuild-dev with different access controls. > > cvs-dev (root cvs access) > cvs-dev-games (games area access) > cvs-dev-misc (misc access) > > cvs user cgianelloni a part of cvs-dev-games and cvs-dev-misc just as an > example. Again you can only take this as far as administration organization > will allow. It can get out of hand too fast if your hard of a dozen area. In > that case just full access for simplicity. > > Then start with ebuild devs > > ebuild-dev, etc, etc > > The difference with them is I would want owner level control assigned so that > yes you can give them ebuild-dev-games but they only have access to the > ebuilds in that area that they've contributed. So it's pretty much the latter to conclude. As said, i don't think restrictions are the way to go. What would be the defining difference between 'cvs-devs' and 'ebuild-devs' anyway ? It looks like it's only a restriction thing. I don't see what it adds besides a lot of administratory cruft and low quality ebuilds. - foser -- gentoo-dev@gentoo.org mailing list