Re: [gentoo-dev] creating ebuilds

[Spider]

begin  quote
On Tue, 6 Jan 2004 09:13:30 -0500
"Allen Parker" <[EMAIL PROTECTED]> wrote:



> 
> 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.

Actually, before this the build should go through several other stages:
 
> 1. New submission is created, submitted to system


1b)  automated repocheck (compare repoman lintool) 

> 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:

3b) QC,  by developer of the strictest sense. A lot of people failto
grasp even the most basic concepts of  ebuild programming and / or the
case of boolean logic. ( if foo then bar ; then baz.....  or was that or
baz?  or ... or.... if foo then bar... then we ignore the case of not
foo?  )



> ** Assuming everything is perfect
> a. Ebuild works fine, no patches need to be applied/software is now
> known stable.

No. its not, we have yet no conclusion as to wether the build is
complete or not. Does it build all documentation? are the files really
with that license?   are the dependencies correct according to
configure.*  or did it just happen to work on a fully installed system? 

Is all functionality accounted for in the dependencies, or will it build
without, say X, but with reduced functionality?  None of this is checked
for, and almost none of them are accountable by automagic.


> b. User response is requested, users vote yay or nay on whether the
> package compiles for them without error.

compare the old "stable.gentoo.org" which was a great idea, but lacked
in ease of use and functionality.

<SNIP>



These checks also fail to scan for upstream behaviour. how does upsteam
deal with versions? do they silently fuck up binary releases in the past
or not, is it actively supported?  how long has the package been alive?
(no, just releasing 0.03 to the public last month doesn't mean its alive
and well)


> 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.




The idea is sorta-good, I'm not too sure it will be feasible in a larger
scale, but one could hope it is.  And definitely, it'd be a good idea to
separate this from bugzilla.

However, this procedure still means that a developer -HAS- to take
responsibility for a package before it goes into the tree, Which is
something a lot of people whine at just now , becuase their favourite
javawrapper for a string() class didn't go into the tree when everyone
should use it,  or because noone (almost) have a  ps2 devkit to try
foo-app....  (Examples , dont take it too badly)

The policy is, all packages in the tree -needs- a developer contact, if
that person is a relay to somone else, or deals with it himself isn't
much of an issue, but if he's a relay to somone who isn't there (oh, got
bored and went to hack on lfs instead)  he still has to deal with it.
Wether dealing in this case means removing the package and deprecating
it, or actively taking over the upstream abandoned source in a futile
attempt to make it build against the new gcc+glibc combo of the week, is
another issue.


Conclusion : please, write a GLEP. i want to see this discussed more,
but in a whole new thread.



//Spider



-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

pgp00000.pgp
Description: PGP signature