Hi,
Alexis Ballier <aball...@gentoo.org>:
> > 4) Nobody knows how work all packages in tree, so there are obvious
> > packages like a browsers, IM, audio player,that is easy decide if is
> > ok or not, but there are also packages that an Arch tester has never
> > seen, so is a lack of time everytime google about it or ask to
> > maintainer, so, please specify what test you want for this package;
> > e.g. -only compile test
> > -compile test and make sure src_test goes well
> > -make sure /usr/bin/${foo} works properly in ${that} manner
> > -see 5) about library
> >
> > So, you can write one time 'how to' and copy/paste for the future
> > stablereq; I guess I'm not asking a long and difficult task.
>
> what i dislike in this approach is that arch testers will follow a
> test plan which the maintainer has obviously tested before and knows
> it works.
> sending people into the jungle of 'try to do something with $pkg' may
> make them encounter problems the maintainer hadnt thought about.To stick with the Emacs example: We barely use all those packages we maintain. So sometimes we do not even execute this documented test plan ourselves. Of course it only contains a small subset of everything, but some test plans contain a "fool around with the program" and it is better than nothing. V-Li -- Christian Faulhammer, Gentoo Lisp project <URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode <URL:http://gentoo.faulhammer.org/>
signature.asc
Description: PGP signature
