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

[Mark Gordon]

On Tue, 22 Apr 2003 15:36:55 -0700
Robin H.Johnson <robbat2@g.o> wrote:

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

If it stays reasonably up to date with bugzilla this could be very
useful. Personally I would not trust any ebuilds in it without manually
checking them since, no offence to Brian, but I don't know him. However,
checking a local synced copy of it would be much faster than checking
bugzilla.

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

Also, I would think that if you are submitting an ebuild for a new
package including a summary of what it is and why it is useful (keep it
short) since then a developer is more likely on seeing it to say, "Wow,
I want that," and get it in to the tree.

If an update to an existing ebuild for a new package version fixes a
major problem, mention that briefly rather than just submitting it to
bugzilla as a version bump.

> 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

Check dependencies are correct? :-)

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

A lot of work is involved in properly checking changes submitted by a
third party, something a lot of people who have not been involved in
full change control systems often don't appreciate. The problem being
that the person authorising the change has to understand it and be able
to verify its correctness. I know because I've been the main person
responsible for this on some large closed source projects where I
personally knew all the other developers.

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

Don't blame you.

I've been reasonably happy because the few things I've submitted have
gone through in a reasonable time frame when the work involved is
considered.

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

Nice to hear it, although to be fair to the other developers there have
been a few posts recently where the developers have said this so us
users really should have got the point that this is being worked on.

Once it is up and running I will probably try to spend more time
watching the packages critical to me which I expect to be less commonly
used. For now, time prohibits me from doing too much.
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Currently looking for a new job commutable from Slough, Berks, U.K.
Although my email address says spamtrap, it is real and I read it.

--
gentoo-dev@g.o mailing list