From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6497 invoked from network); 21 May 2004 16:29:32 +0000 Received: from smtp.gentoo.org (156.56.111.197) by parrot.ussg.indiana.edu with SMTP; 21 May 2004 16:29:32 +0000 Received: from parrot.ussg.indiana.edu ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BRCtm-0003Rh-2d for arch-gentoo-dev@lists.gentoo.org; Fri, 21 May 2004 16:29:30 +0000 Received: (qmail 1723 invoked by uid 89); 21 May 2004 16:29:22 +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 23903 invoked from network); 21 May 2004 16:29:22 +0000 Message-ID: <1525.24.123.50.150.1085156959.squirrel@mail.jmglov.net> In-Reply-To: <1085151850.878.7.camel@gs75.geol.vt.edu> References: <200405201846.37173.cbrewer@stealthaccess.net> <1085145580.8753.93.camel@newkid.milsson.nu> <1085146797.25036.52.camel@localhost> <200405211554.06946.c.j.bainbridge@ed.ac.uk> <1085151850.878.7.camel@gs75.geol.vt.edu> Date: Fri, 21 May 2004 12:29:19 -0400 (EDT) From: "Josh Glover" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: Re: [gentoo-dev] Stuff that makes people mad X-Archives-Salt: 918600fc-df73-4f59-8ad6-9792e0d963f9 X-Archives-Hash: 1a7aa4825abf1eb0f45445001dfb64af Quoth Stephen Becker: > >> There ought to be some sort of procedure for dealing with user >> submitted ebuilds. I would suggest a system of putting them in ~x86 (o= r >> whatever) immediately, and if there are no bug reports for x days move= them >> to x86. > > The problem with this idea is that the developers would lose control on > consistency and quality of ebuilds in portage. Just because you might > be good at writing an ebuild doesn't mean that everyone knows what they > are doing. We could end up having software installed to silly places > and/or non-standard config file storage, which would be very less than > desirable. There is a reason that we are required to take a test to > become developers, part of that being to know what to do and what not t= o > do when writing ebuilds and/or accepting them to add to portage. I agree with both sides, here. It would be lovely to get user-submitted ebuilds into Portage more quickly, but there are serious QA issues. I wonder if we can design an ebuild-lint tool to validate ebuilds automatically. It could work something like this: 1. User submits an ebuild to Bugzilla 2. ebuild-lint runs on it (out of cron, maybe) 3. If ebuild lint finds problems, the user is emailed with a laundry list= of things to fix 4. When ebuild-lint finds no errors with the ebuild, then and only then i= s the ebuild brought to the attention of bug-wranglers, who would assign it = to the proper herd. This way, the number of seriously bad ebuilds would be cut down, so the signal-to-noise ratio for user-submitted ebuilds should improve greatly, allowing the devs to give the ebuild a quick once-over before sticking it Portage (keyword-masked as unstable, of course). I am sure this idea has flaws, but the basic flow seems good. Comments? --=20 Josh Glover GPG keyID 0xDE8A3103 (C3E4 FA9E 1E07 BBDB 6D8B 07AB 2BF1 67A1 DE8A 3103) gpg --keyserver pgp.mit.edu --recv-keys DE8A3103 -- gentoo-dev@gentoo.org mailing list