Re: [gentoo-dev] Ebuilds not getting in :(

[Robin H.Johnson <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3778 bytes --]

On Tue, Apr 22, 2003 at 05:07:22PM -0500, Brian Jackson wrote:
> Nobody showed an interest, but here it is anyway:
> http://www.mdrx.com/brian/portage-local.tar.bz2
> There could be a lot more stuff there, and if anybody shows any interest, I 
> will probably try to setup an rsync server for people to pull from instead of 
> having to download and extract.
I think this is actually a great idea for now, as an extra testing
ground for some of the ebuilds.

As a developer, I do occasionally merge a number of minor ebuilds that I
need myself and are just sitting in the bugzilla tree, and then I keep
an eye on them.

The since most discougaging thing in any submitted ebuild is the lack of
an included ChangeLog. To anybody submitting an ebuild, use
skel.ChangeLog, and fill it out with the correct information.
Additionally, for many of your ebuilds, in your posting about the bug
specify what you did and why. It saves us a lot of trouble in 
testing the ebuild. Also make sure that your ebuild installs ALL of the
documentation that is distributed with the source package. Take a look
at /usr/share/doc and see how comprehensive some packages are in this
regard. Don't forget the manpages either (a fairly common mistake).

If you have a question about how to do something in an ebuild, look at
other ebuilds or ask on this mailing list.

If there is an ebuild that is totally ready to go out (eg I _could_ just
dump the files into a new directory and check them in. I don't for
security and QA reasons) of the box, it
greatly increases the chance that it will get into the tree quickly.
Very few submitted ebuilds come up to this level. I will admit that it
is a lot to ask for, but it really makes life as a developer much
easier.

Personally, for any ebuild I am willing to pick up, I generally do the
following:
0. read the submitted ebuild AND changelog
1. grab the source tarball
2. read the included documentation
3. read the documentation on the web and other information I can find
about it
4. re-read the included documentation
5a. attempt to compile it only inside a sandbox enviroment
5b. if problems from 5a, look at some of the source code/ebuild to
figure out why
6. see what 'make install' or the other standard methods of install
WOULD install and compare that to the ebuild install instructions.
7. install it on a testbed system and do some simplistic functionality
and security (trojaning) checks
8. install it on 3-5 other systems with widely varying configurations to
see if it installs cleanly in most cases.
9. commit to CVS

Generally this process is spread anywhere between 6 hours and a week
long, depending on package complexity and how busy I am with
work/school and my other open source work (I'm a developer on
phpMyAdmin).

19 times of of 20, if a submitted ebuild is more complex than
emake/einstall and doesn't include a changelog or some detailed comments
inside the ebuild as to what is being done, then I don't touch it.

Definetly having more developers/maintainers would help, but there are
many issues around this (as people have pointed out in the thread).
Debian's "solution" to many of the problems was a dedicated maintainer
for each package, and only a few packages per maintainer to keep things
managable, but that requires a LOT of maintiners/developers. There are
some changes under discussion for Gentoo on this presently, but I won't
say more now, as not to get people's hopes up for the outcome as it
could change a lot.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]