Hi,
On Wed, 18 Jan 2012 15:23 +0100
Agostino Sarubbo <a...@gentoo.org> wrote:
> 2) _Before_ filing a request, please run repoman full, to be sure
> that there is nothing to fix, then take a look at the ebuild and make
> sure your ebuild have a minimum of QA; all external binary called in
> the ebuild(sed, mv, cp, ln, rm, and so on) should have 'die'; if you
> don't use EAPI4, make sure that all portage helper[2] have also '||
> die'.
>
> 3) Check your rdepend, where is possible with scanelf[3] and if you
> declare it, please, as you said, exclude gcc/glibc and all package
> from @system
imho this has nothing to do with stabilization, every single package
should have these 2 points addressed.
however, fact is that a second pair of eyes reviewing the ebuild (which
is what arch testers usually do) usually spots more than the author.
there are obvious problems (reports from repoman) that indeed
should be fixed before asking for stabilization, but others are more
difficult to spot (automagics, missing die's/typos), and, as a
maintainer, the reviewing done by arch testers is usually a good help.
> 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.
Regards,
Alexis.
