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