Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Henti Smith]

On Tue, 29 Apr 2003 19:44:41 +0000
Mikael Andersson <snikkt@×××××.com> wrote:

> Gentoo is moving to slow this is why this kind of ideas emerge. It might be
> moving fast, but obviously still too slow for many. I've got a few ebuilds
> done which i haven't even bothered to try to get in since i've seen the queue
> in bugzillla and I'm sure several others are in the same situation.

Agreed ..

> Communication between developers and users is always hard. Esp since many
> gentoo users isn't strictly users. Some of the points i make might sound a
> bit harsh - but try to smile while you read them - i think it will make
> gentoo a better distribution if you do .)

Personally .. I think a good "how to build ebuilds" would help alot if not a ebuild spacific 
mailling list. This way I can submit questions I have or ebuild for testing before submitting them to 
bugzilla ... 

I use existing ebuilds as a base for new ones since the skel in /usr/portage is really not that helpfull when you doin git for the first time.
Maybe change skel can be a fully functional ebuils to do ummm .. nothing .. but have valid and correct ebuild structures and ways of doing things 
to help guide a new ebuilder in the right direction.

I've had ebuilds that does wierd things that I don't understand .. and have asked for comments in bugzilla and on devel
list but got no reply.

this makes it hard to understand what I'm doing wrong or right .. 

> > Go back and read my posting about why many ebuilds don't get into the
> > tree.
>
> I didn't see a lot of comments about the ebuild not being up to par in
> bugzilla. Maybe if a developer seeing a build not beeing 'good-enough' could
> add a small note about this so we - The Users(tm)  - or in another word, the
> user community [3] can fix whats wrong. We aim to please ...

I think the suggestion of a ebuild mailling list for ebuild developers could be helpfull here as well.

> No need to yell, instead add that information to [1]. In a way it's written in
> [2] but as that is targeted for developers it's hard to know whether or not
> I'm required to add that to my update, and if i should attach another file
> with the entire changelog/changelog entry. And equally important, somebody
> with the proper knowledge should get lintool online again. Apparently it's
> broken ( see warnings in [2] ) and sure enough it reports errors for
> baselayout and other core packages so it's probably at least somewhat broken.
> >
> > > I have come back to the new versions of the software... In a completely
> > > new system, and the ebuild works fine.
> >
> > Is libcap even actively maintained still? If not and it is not widely
> > used, then it is not likely to get into the tree at all.
>
> Maybe Larry the cow will stop using gentoo then ? After all he liked being in
> control. If the users isn't in control gentoo will stop beeing bleeding edge
> and maybe end up only bleeding.

The time it takes to get feedback is discouraging ... I have helped with the ebuild for openexr and since then a new version has been released which I 
submitted and then an update to work with nv-cg-toolkit and the NVSDK and still no feedback ... 

I understand there are things happening to correct this and I'm waiting in antisipation for those changes as the only real 
contribution I can make to gentoo is bug reporting and ebuilds ... I'm doing lots of bug reporting ... but only one ebuild I had any interaction with has been 
incorporated into the tree. 

> > If you resolve all of the above issues, and the package is still widely
> > used (I want some proof of this), then I'll take the ebuild and maintain
> > it in portage myself.
>
> Well, this is a problem since not all packages wanting to be in portage will
> be widely used. But i have hopes that these kind of problems will be resolved
> with the restructuring of ebuild submission and maintainance in progress.

If you meet a hungry man and give him a fish .. he eats for a day ... give him a fishing rod and he eats for a live time
I knwo it's cliche'd .. but it's because it's true .. 

It will take alot less effort in the long run to help a "new" developer get it right and then monitor him to make sure he knows what 
he's doing then he can maintain he's own package. 

I do however thing a proper document on how to create correct ebuilds will go along way to helping ebuilders do things right.
What is required etc etc. Sinply reading the emerge and ebuild documentation is not enought to understand the inner workings of the ebuild,
and it has changed quiet a bit in the last few months.

Once again I suggest a ebuild mailling list with the sole use of creating discussing and testing new ebuilds .. 

Henti 

--
gentoo-dev@g.o mailing list