Gentoo Archives: gentoo-dev

From: Karl Trygve Kalleberg <karltk@×××××××.no>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Contribute many ebuilds at once
Date: Sun, 09 Jun 2002 10:57:00
In Reply to: Re: [gentoo-dev] Contribute many ebuilds at once by Marko Mikulicic
1 On Sun, 9 Jun 2002, Marko Mikulicic wrote:
3 > > The new system tries to resolve that.
4 >
5 > What are the main reasions for this latency ?
7 In my experience, the latency is that each submitted ebuild is usually
8 malformed in some way. Which means that I have to spend time clean it up
9 before I commit it.
11 Worst example so far was an ebuild that depended on "GLP-2", but did not
12 have a license set. Of course, what the author meant was that the
13 package's license was "GPL-2", and he didn't know of any dependencies (so
14 I had to figure out those as well).
16 In the end, it turned out that the package was in the public domain, just
17 to make my day perfect....
19 But it was such an important package (subjectively), that I elected to
20 spend the necessary time to essentially rebuild it from scratch.
22 > I imagine the package need to be tested somehow.
24 Yes, in the above case, a "screener" script would detect that there is no
25 package named "GLP-2", and also warn the author that an empty license is
26 not acceptable.
29 > How is this "new system" you are talking about ?
31 It is wonderful ;P
33 > How is the "old system", from a maintainer perspective ?
35 It can be very time-consuming. Especially considering bugzilla's
36 less-than-elegant way of handling uploaded submissions (filenames are
37 lost).
39 > What appens "afterwards" ?
41 Bit rot, usually. How to keep the packages in the tree working slickly
42 all of the time is a massive problem that we are taking steps to handle,
43 but there is only so many developers and so little time [and our pesky
44 users keep submitting bugs and suggestions for improvements that we have
45 to deal with along the way also... :P]
47 > Wouldn't be nice if new ebuilds would committed to
48 > a middle place (purgatory) where they wait in a queue.
49 > But in the mean time audacious users could try the ebuilds
50 > (simply downloading them with ftp, or ebuild rsyinc-purgatory ->
51 > /usr/portage/purgatory) so at least they can be tested.
52 > Does it make sense ?
54 Yes. Variants of this have been suggested already. The first step would be
55 for end-users to be able to browse the ebuild submission pipeline.
56 This way, they could see whether the ebuild passes all
57 automatic conformance tests, whether it actually compiles, comments from
58 developers (if any).
60 Also, interested users could download the ebuild (probably packaged in a
61 .zip file with associated digest, auxiliary files and changelog), so that
62 they could just unpack/splice it into their local portage tree to test it.
64 By making this process more open, interested end-users would be able to
65 help out the development by detecting/fixing/reporting issues at an early
66 stage.
69 Karl T