From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30093 invoked from network); 6 Jan 2004 14:13:35 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 6 Jan 2004 14:13:35 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1Adrxe-0006V9-Ei for arch-gentoo-dev@lists.gentoo.org; Tue, 06 Jan 2004 14:13:34 +0000 Received: (qmail 21053 invoked by uid 50004); 6 Jan 2004 14:13: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 5441 invoked from network); 6 Jan 2004 14:13:31 +0000 From: "Allen Parker" To: "'Caleb Tennis'" , Cc: "'Ken Menken'" Date: Tue, 6 Jan 2004 09:13:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200401060808.12701.caleb@gentoo.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPUVpNLliXNuDK3Ty+CxtjXkICArQAA4z8A Subject: RE: [gentoo-dev] creating ebuilds Message-Id: X-Archives-Salt: f6b96a76-0109-4dfb-acf3-2af6c2fa31f8 X-Archives-Hash: 6735396519c0f6dd551b5b3668d4fd2c > On Tuesday 06 January 2004 04:54 am, Kurt Lieber wrote: > > I could see benefits to having a dedicated person, who was extremley > > knowledgeable in the ins/outs of ebuild creation who did nothing else > > except scan bugs.gentoo.org for new ebuilds and put them into the tree. > > Whether there's a person out there with the right skill set willing to > do > > such a job is another question entirely. (not saying there isn't, btw) > > This is a bad idea, IMHO. I used to think more in favor of it, but if > someone > really wants an ebuild that isn't in portage they can very easily search > bugzilla, download the ebuild, and put it in their overlay. > > What would be more beneficial is if there was a repository where > unaccepted > ebuilds go after a period of time > (http://www.gentoo.org/proj/en/glep/glep-0017.html). That way, people who > want to use those ebuilds can download them from there. I think I should definitely re-state my *ideal* system for ebuild submission, since it wasn't understood. Bugzilla is great, I agree, but it's for *bugs* and as was said earlier, if a dev isn't interested in an ebuild, it's not going into the tree. Here's the process that I suggest, and I think it'll streamline things and reduce the workload on ebuild submission. Avenj, this does NOT require people like me to have CVS access. 1. New submission is created, submitted to system 2. System sees new ebuild, notifies submitter, dev that has notified system that they have free time, and possibly herd maintainer for ebuild's proposed home (opt-in via web interface). 3. Dev checks in, sees ebuild, downloads ebuild, attempts build. Here, things split: ** Assuming everything is perfect a. Ebuild works fine, no patches need to be applied/software is now known stable. b. User response is requested, users vote yay or nay on whether the package compiles for them without error. c. Dev ok's and ~ARCH's ebuild, system picks that up and spits it into /usr/portage/ebuild-submits/ (which can be specifically defined as a PORTDIR_OVERLAY, and is undefined as per default) d. User is happy, dev doesn't have to spend too much time messing with things, and when they get time to check the package out more thoroughly, it can be "moved" to the main tree via the interface. ** Possible "gotchas" for submitter: A. System does a basic syntax check and rejects Ebuild due to syntax errors. B. Ebuild is ok'd by system for syntax, but when ebuild is attempted in a sandbox, by dev or "trusted" user, fails and is kicked into another area where the submitter now has to figure out if it's the ebuild or the package. (Possible chroot'd script for auto-testing via ebuild .ebuild digest with failures going to submitter, if no failures, ebuild -v .ebuild package, with errors going to submitter. (queued ebuilding via a distcc cluster would probably be preferable on this) C. Human review, information attached to the ebuild is incomplete, automatic 1 week suspension of submitter from system with 5 or more complaints from their peers or 1 complaint from a dev. If package does not have a listed "stable" release, ebuild is thrown out via the above conditions. D. Ratings: The more successful ebuild submissions you've got, the better chances you have for having your ebuild moved to the main tree quickly. E. Existing packages are *NOT* acceptable for submission. New packages only!! If the system finds that there is an existing ebuild for whatever it is you're attempting to submit, the ebuild will automatically be dropped (${PN} matching, maybe md5 distfile db scans or more?) This is just a rough idea of a way to streamline things. If non-gentoo devs work on this, it shouldn't take too long to see if it'll sink or swim. IMHO, Bugzilla is a great thing, it just isn't suited very well or even designed for this task. I think Bugzilla should be for bugs with existing software... not ebuild submission. With the proper checks, it should be possible to use a system for ebuilds only that can handle revision-bump requests, new ebuild submissions, and possibly more, without overloading bugzilla OR the Gentoo-devs. At no point would ANY non-dev be allowed direct cvs access (1 week sandbox before going into ebuild-submits overlay for last-minute checking by devs). At no point would any non-dev have access to anything that could be considered a security risk, in fact, with one of the ebuilds I was working on developing, it would be possible to setup multiple "virtual" build systems with immutable linking on every file that could be a hazard (which via cron, the whole build environment could be cleared and reset every 24 hours without a problem) rm -rf /vservers/genbuild && cp -la /vservers/genskel /vservers/genbuild would take care of it with anything that could be possibly used to hurt someone else's work chattr +it (to keep from being trojanned). That's my 2/100ths of a monetary unit. Allen Parker PS. I hope I cleared some misconceptions up, I wasn't suggesting that non-devs be allowed cvs access, only that a system would be put into place that would automate things, because I know for a fact that the ebuild submission process as it stands isn't really a process, it's an abomination. (if you'd like an idea how I figured this out, I was thinking of making vserver-sources, vserver and util-vserver ebuilds... months later, I have nothing solid, and I don't have the time to chase people around to get an ebuild in the tree... and it doesn't seem right.) -- gentoo-dev@gentoo.org mailing list