| 1 |
On Sun, 9 Jun 2002, Marko Mikulicic wrote: |
| 2 |
|
| 3 |
> > The new system tries to resolve that. |
| 4 |
> |
| 5 |
> What are the main reasions for this latency ? |
| 6 |
|
| 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. |
| 10 |
|
| 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). |
| 15 |
|
| 16 |
In the end, it turned out that the package was in the public domain, just |
| 17 |
to make my day perfect.... |
| 18 |
|
| 19 |
But it was such an important package (subjectively), that I elected to |
| 20 |
spend the necessary time to essentially rebuild it from scratch. |
| 21 |
|
| 22 |
> I imagine the package need to be tested somehow. |
| 23 |
|
| 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. |
| 27 |
|
| 28 |
|
| 29 |
> How is this "new system" you are talking about ? |
| 30 |
|
| 31 |
It is wonderful ;P |
| 32 |
|
| 33 |
> How is the "old system", from a maintainer perspective ? |
| 34 |
|
| 35 |
It can be very time-consuming. Especially considering bugzilla's |
| 36 |
less-than-elegant way of handling uploaded submissions (filenames are |
| 37 |
lost). |
| 38 |
|
| 39 |
> What appens "afterwards" ? |
| 40 |
|
| 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] |
| 46 |
|
| 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 ? |
| 53 |
|
| 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). |
| 59 |
|
| 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. |
| 63 |
|
| 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. |
| 67 |
|
| 68 |
|
| 69 |
Karl T |
Archives