Re: proving a bug is gone
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 <phil@hands.com> 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 * bhmit1@mail.wm.edu * http://bhmit1.home.ml.org/ |
| Sometimes you have to release software with bugs. - MS Recruiter |
Reply to: