=====FROM LUX=====

Hello Dave,

* Davesurrey wrote
Firstly you have identified the source of the problem and the fix. Many thanks.

Thank you for reporting your experience with ntop. I improved it, but I regret I had no time to improve it more and look for the smallest possible needed dependence.

* Davesurrey wrote
That is, one really must start with a clean install to be absolutely sure that an app works in isolation.

Absolutely!

But let me recall that this is the job of contributors, who provide new packages to Slitaz, not the devs, who in my opinion are the very heart of the developement staff, those who built the whole project from the beginning and make it evolving over the long distance. If those very few people (less than 10, maybe 5 persons, maybe even less) would spend more time controlling every single package submitted by contributors, they would no longer be able to develop the distro anymore. There is a balance to find between growth and stability, between creativity and rigour, and this is not obvious since it's also a mater of personal taste.

I think that Slitaz has grown up very fast, thanks to a very little number of enthousiastic people who did an amazing job. So it would not be fair to complain too much on this. Also remember that "Cooking" means "unstable" in Slitaz.

OK, but how to improve it now? Let's consider three possibilities.

- 1 - Testing protocol
I don't know how the whole staff (devs and contributors) works, but maybe it would be a good idea to define some more rigid guidelines for contributors in the sense that including a new package in the distro wouldn't be possible without having followed some pre-defined testing steps, like:
* install the package in a freshly built default Slitaz environment;
* do not try it only in virtual box or a chrooted environment (I'm not a specialist of this but I'm convinced that it is too far from real conditions);
* see what happens if you change:
     - the langage (what about translations?);
     - the boot process (start with an X session from the beginning or from a text mode connection followed by a call to startx can change things);
     - the user (try it as root and as tux);
     - the location of the package (I think that the new version of taspkg allows to dispatch the binaries between several locations);
     - the window manager maybe;
* and so on...

- 2 - Testing team
It may be that defining such a testing protocol won't be sufficient and that some contributors will "interpret" it in their own way. If so, electing a permanent "testing team" might be a solution in order to ensure that the distro will remain reasonably stable (are you a candidate for this job?). I'm not sure that this matches the idea of a TAZ ;-) so let's consider:

- 3 - Testing community
It may be that testing existing packages is the role to play by the community of users of the non-stable release of a distro (you, me...) after all.

Now let's wait and see if the devs have an opinion on this.

Regards,
LuX.

PS: By the way, it might be a good idea to maintain an up-to-date "Core-Cooking" flavor just for testing purposes (as far as I know the core flavor is a subset of the stable release). It has also been often asked in this forum that the Cooking iso is made up-to-date on a regular basis, say once a week. I don't know if it is possible, but it would certainly help also for testing purpose: if after every fresh install you have to upgrade 267 packages, very soon you'll stop to re-install and give up with this essential step for testing a new package.