RE: [gentoo-dev] creating ebuilds

[Allen Parker]

> 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 <package>.ebuild
digest with failures going to submitter, if no failures, ebuild -v
<package>.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@g.o mailing list