On 8 Nov 1998, Adam Di Carlo wrote: > >> The debian-testing group is actually working on this issue as well, > >> someone should liase with them.
> > Agreed. But I'm at a loss here -- I don't see a debian-testing > > mailing list, and I don't see any testing links off of the > > developer's corner of the web site. It should be listed in /usr/doc/debian/mailing-lists.txt. I just talked with Guy yesterday about getting us archived with the other mailing list, so the next time the archive program runs, maybe we'll show up. > Yeah, well, I'll CC them here (naughty of me to cross-post, I know). > Maybe the list maintainer can clue you in. To be honest, it *should* > be a normal, first class, archive-browsable list. There's no reason > why it isn't; <debian-testing> is not a cabal. :) Thanks for the CC. Right now we don't have the man power to do full blow individual testing of individual packages. We decided we wanted several things: 1) users ability to run test scripts (testers are often users, downloading the source would be a pain) 2) testing scripts should be able to be easily filtered out by directory (when that feature is added to apt) and separated into other packages 3) the testing group should be able to make a script if the package maintainer doesn't have the ability/desire, which is maintained by us, not them, but which the maintainer could override by adding a test script to their own package 4) we need some standard output from these scripts 5) probably some other things that I can't think of now Philip Hands <[EMAIL PROTECTED]> took the time to put together a simple perl script that does this and packaged it into a program called debian-test. As you can tell by the version number, it's just something to get us started with, wishlist bugs are welcome. > Raul, I really think the proof is in the pudding. If you can help > shape a working, easy enough to manage test suite, and start filling > that in (even, just start with base packages), we'll be able to look > at it from there and decide if there's a policy to be written or not. The structure is there to work with. It would be good if bugs caused an addition to the test script to be made when they are closed, but I think this is a bit demanding right now. Something to think about: what about programs that have a gui interface and libraries, how do you want to test those? Ok, you can make sure only programers are packaging libraries, but that's a pain. Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | Sometimes you have to release software with bugs. - MS Recruiter | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
