Sorry, I couldn't read all the posts :-) so I may duplicate some advices. However I thing the discussion is taking a wrong direction. We, here, are talking of driving a _distribution_, not a test site for individual packages. There are already very nice repositories for developpers, not to mention Sourceforge. Why duplicate them? Package tests is the work of _package developpers_, not _distribution developpers_. Here, we need just see if the package inserts itself well in the actual SUSE 10.0. Only bug resorting on this insertion are of our goal, not bug about the package itself. It's a all work in itself :-) IMHO the first goal we should acheive rapidly is a categorisation of the packages and a (?) vote system to know what package must be included among all of the same kind. For example, what cd writer package do we need? what editor? of course it can be a "s" at any one (we can choose more than one). For most of these packages we then can, as it's already done, use the actual source. then, we can setup a "new package proposal commission". That is a group that goal is to make a survey on the new apps available elsewhere. _not_ to host them and debug them, but to look at the already done work and see if it may be included (list of dependencies...). If a package seems promising, a member of the commission could be in charge to join the package dev team in the goal of making a SUSE 10.0 rpm. Usualy it's a volunteer who makes suse rpm for not distro included product (was the case, I remember for lyx or audacity at the beginning). And then the new package go to the category folders. Of course we can have packages sorted also in "included", "optional", that is tested, available on the ftp, but not on the CD's, "untested" (that is proposed by voluteers, but not yet tested by the opensuse team). should also be a category "rejected", for example for impossible to meet dependencies. sincerely jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr