| 1 |
On Sun, 9 Jun 2002, Marko Mikulicic wrote: |
| 2 |
|
| 3 |
> I want just to avoid duplicate work, in case someone feels |
| 4 |
> the need to use, say wmtop, and than wm*; sure they are |
| 5 |
> nice apps to start understanding portage, because they are small, |
| 6 |
> but if someone already did that three weeks ago without telling .... |
| 7 |
> aargh :-) |
| 8 |
|
| 9 |
Increasing the visibility of which ebuild submissions are in the pipe is |
| 10 |
something we'd very much like to do. It is a fairly easy affair, and will |
| 11 |
probably be handled in my proposition for a new ebuild submission system. |
| 12 |
|
| 13 |
|
| 14 |
> I would like to help developing a flexible command line submission |
| 15 |
> system. I'm interested in how are you currently organized, how and who |
| 16 |
> read the "bug" submissions ... |
| 17 |
|
| 18 |
Currently, we have a set (with cardinality of one) of bug wranglers |
| 19 |
that traverse the list of incoming bugs periodically, then assign each bug |
| 20 |
to a suitable developer. |
| 21 |
|
| 22 |
Then each developer will traverse his bug list, picking out bugs in the |
| 23 |
order of subjective importance, and commit fixes/updates to our CVS. |
| 24 |
|
| 25 |
It is a simple, two-step procedure. |
| 26 |
|
| 27 |
> Alternatively I could write a dummy client which connects to the |
| 28 |
> bugzilla like a webbrowser and automates the submission. |
| 29 |
|
| 30 |
The biggest problem for the maintainers is the varying quality of ebuilds. |
| 31 |
Few, if any submissions are correct on the first go, and many of the |
| 32 |
bugs/problems identified could be checked programmatically. |
| 33 |
|
| 34 |
Submissions should then be run through a "screening" script that checks |
| 35 |
for syntactic and semantic completeness, verifies dependencies, |
| 36 |
well-formedness of ebuild, digest, changelog, etc. |
| 37 |
|
| 38 |
If any of these tests fail, the submitter is notified, and no developers' |
| 39 |
time is wasted needlessly until the ebuild script follows all the basic |
| 40 |
guidelines and its sources actually compile. |
| 41 |
|
| 42 |
> (I suppose there is not a secure straight connection to the bugzilla |
| 43 |
> backend) |
| 44 |
|
| 45 |
Not afaik, and it will not be a wise path at any rate. |
| 46 |
|
| 47 |
> I see all this by a user perspective, not as a maintainer; so I would |
| 48 |
> like to learn more. |
| 49 |
|
| 50 |
That is excellent, because admittedly, some of us have lost some of that |
| 51 |
perspective somewhere along the way. |
| 52 |
|
| 53 |
|
| 54 |
Karl T |
Archives