| 1 |
begin quote |
| 2 |
On Tue, 6 Jan 2004 09:13:30 -0500 |
| 3 |
"Allen Parker" <allenp@×××.org> wrote: |
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
> |
| 8 |
> I think I should definitely re-state my *ideal* system for ebuild |
| 9 |
> submission, since it wasn't understood. Bugzilla is great, I agree, |
| 10 |
> but it's for *bugs* and as was said earlier, if a dev isn't interested |
| 11 |
> in an ebuild, it's not going into the tree. Here's the process that I |
| 12 |
> suggest, and I think it'll streamline things and reduce the workload |
| 13 |
> on ebuild submission. Avenj, this does NOT require people like me to |
| 14 |
> have CVS access. |
| 15 |
|
| 16 |
Actually, before this the build should go through several other stages: |
| 17 |
|
| 18 |
> 1. New submission is created, submitted to system |
| 19 |
|
| 20 |
|
| 21 |
1b) automated repocheck (compare repoman lintool) |
| 22 |
|
| 23 |
> 2. System sees new ebuild, notifies submitter, dev that has notified |
| 24 |
> system that they have free time, and possibly herd maintainer for |
| 25 |
> ebuild's proposed home (opt-in via web interface). |
| 26 |
> 3. Dev checks in, sees ebuild, downloads ebuild, attempts build. Here, |
| 27 |
> things split: |
| 28 |
|
| 29 |
3b) QC, by developer of the strictest sense. A lot of people failto |
| 30 |
grasp even the most basic concepts of ebuild programming and / or the |
| 31 |
case of boolean logic. ( if foo then bar ; then baz..... or was that or |
| 32 |
baz? or ... or.... if foo then bar... then we ignore the case of not |
| 33 |
foo? ) |
| 34 |
|
| 35 |
|
| 36 |
|
| 37 |
> ** Assuming everything is perfect |
| 38 |
> a. Ebuild works fine, no patches need to be applied/software is now |
| 39 |
> known stable. |
| 40 |
|
| 41 |
No. its not, we have yet no conclusion as to wether the build is |
| 42 |
complete or not. Does it build all documentation? are the files really |
| 43 |
with that license? are the dependencies correct according to |
| 44 |
configure.* or did it just happen to work on a fully installed system? |
| 45 |
|
| 46 |
Is all functionality accounted for in the dependencies, or will it build |
| 47 |
without, say X, but with reduced functionality? None of this is checked |
| 48 |
for, and almost none of them are accountable by automagic. |
| 49 |
|
| 50 |
|
| 51 |
> b. User response is requested, users vote yay or nay on whether the |
| 52 |
> package compiles for them without error. |
| 53 |
|
| 54 |
compare the old "stable.gentoo.org" which was a great idea, but lacked |
| 55 |
in ease of use and functionality. |
| 56 |
|
| 57 |
<SNIP> |
| 58 |
|
| 59 |
|
| 60 |
|
| 61 |
These checks also fail to scan for upstream behaviour. how does upsteam |
| 62 |
deal with versions? do they silently fuck up binary releases in the past |
| 63 |
or not, is it actively supported? how long has the package been alive? |
| 64 |
(no, just releasing 0.03 to the public last month doesn't mean its alive |
| 65 |
and well) |
| 66 |
|
| 67 |
|
| 68 |
> This is just a rough idea of a way to streamline things. If non-gentoo |
| 69 |
> devs work on this, it shouldn't take too long to see if it'll sink or |
| 70 |
> swim. IMHO, Bugzilla is a great thing, it just isn't suited very well |
| 71 |
> or even designed for this task. I think Bugzilla should be for bugs |
| 72 |
> with existing software... not ebuild submission. With the proper |
| 73 |
> checks, it should be possible to use a system for ebuilds only that |
| 74 |
> can handle revision-bump requests, new ebuild submissions, and |
| 75 |
> possibly more, without overloading bugzilla OR the Gentoo-devs. |
| 76 |
|
| 77 |
|
| 78 |
|
| 79 |
|
| 80 |
The idea is sorta-good, I'm not too sure it will be feasible in a larger |
| 81 |
scale, but one could hope it is. And definitely, it'd be a good idea to |
| 82 |
separate this from bugzilla. |
| 83 |
|
| 84 |
However, this procedure still means that a developer -HAS- to take |
| 85 |
responsibility for a package before it goes into the tree, Which is |
| 86 |
something a lot of people whine at just now , becuase their favourite |
| 87 |
javawrapper for a string() class didn't go into the tree when everyone |
| 88 |
should use it, or because noone (almost) have a ps2 devkit to try |
| 89 |
foo-app.... (Examples , dont take it too badly) |
| 90 |
|
| 91 |
The policy is, all packages in the tree -needs- a developer contact, if |
| 92 |
that person is a relay to somone else, or deals with it himself isn't |
| 93 |
much of an issue, but if he's a relay to somone who isn't there (oh, got |
| 94 |
bored and went to hack on lfs instead) he still has to deal with it. |
| 95 |
Wether dealing in this case means removing the package and deprecating |
| 96 |
it, or actively taking over the upstream abandoned source in a futile |
| 97 |
attempt to make it build against the new gcc+glibc combo of the week, is |
| 98 |
another issue. |
| 99 |
|
| 100 |
|
| 101 |
Conclusion : please, write a GLEP. i want to see this discussed more, |
| 102 |
but in a whole new thread. |
| 103 |
|
| 104 |
|
| 105 |
|
| 106 |
//Spider |
| 107 |
|
| 108 |
|
| 109 |
|
| 110 |
-- |
| 111 |
begin .signature |
| 112 |
This is a .signature virus! Please copy me into your .signature! |
| 113 |
See Microsoft KB Article Q265230 for more information. |
| 114 |
end |
Archives