Bill Allombert writes ("Re: Automated testing - design and interfaces"):
> Currently Debian packages are tested through a lot of channel:
> [stuff]Right. > Debian is an organisation which can afford a lot of decentralisation, > but where centralisation is very expensive [...] Right. > Doing the checks in debian/rules is not perfect, but it happens before > the package is uploaded, is performed for all architecture and more > importantly is done with the current infrastructure. A big problem is that doing the checks in debian/rules will fail to spot many obvious packaging mistakes. > Going toward a centralised testing facility [...] This is one of the things that Ubuntu will be using it for. But one of the things that I expect Debian to use the same facilities for is to allow a developer to do a test of the package they're about to upload, _after building and installing it_. This might, just as one example, help get rid of a lot of the `NMU broke it totally'. And, of course, there have been occasions when the maintainer didn't really test the package after installing it because it was too much trouble. If it can be standardised and automated, and if a way can be found for Ubuntu to share tests with Debian, then everyone wins. > If Ubuntu want to improve the testing coverage, you could start by > submitting patches to packages that don't run test-suite in > debian/rules. That would profit both Debian and Ubuntu and there are > lot of work to do there. Running the upstream test suite in debian/rules usually isn't the answer to packaging mistakes, library mismanglements, and the like. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
