1 |
Hi, |
2 |
|
3 |
On Wed, 18 Jan 2012 15:23 +0100 |
4 |
Agostino Sarubbo <ago@g.o> wrote: |
5 |
|
6 |
> 2) _Before_ filing a request, please run repoman full, to be sure |
7 |
> that there is nothing to fix, then take a look at the ebuild and make |
8 |
> sure your ebuild have a minimum of QA; all external binary called in |
9 |
> the ebuild(sed, mv, cp, ln, rm, and so on) should have 'die'; if you |
10 |
> don't use EAPI4, make sure that all portage helper[2] have also '|| |
11 |
> die'. |
12 |
> |
13 |
> 3) Check your rdepend, where is possible with scanelf[3] and if you |
14 |
> declare it, please, as you said, exclude gcc/glibc and all package |
15 |
> from @system |
16 |
|
17 |
|
18 |
imho this has nothing to do with stabilization, every single package |
19 |
should have these 2 points addressed. |
20 |
however, fact is that a second pair of eyes reviewing the ebuild (which |
21 |
is what arch testers usually do) usually spots more than the author. |
22 |
there are obvious problems (reports from repoman) that indeed |
23 |
should be fixed before asking for stabilization, but others are more |
24 |
difficult to spot (automagics, missing die's/typos), and, as a |
25 |
maintainer, the reviewing done by arch testers is usually a good help. |
26 |
|
27 |
|
28 |
> 4) Nobody knows how work all packages in tree, so there are obvious |
29 |
> packages like a browsers, IM, audio player,that is easy decide if is |
30 |
> ok or not, but there are also packages that an Arch tester has never |
31 |
> seen, so is a lack of time everytime google about it or ask to |
32 |
> maintainer, so, please specify what test you want for this package; |
33 |
> e.g. -only compile test |
34 |
> -compile test and make sure src_test goes well |
35 |
> -make sure /usr/bin/${foo} works properly in ${that} manner |
36 |
> -see 5) about library |
37 |
> |
38 |
> So, you can write one time 'how to' and copy/paste for the future |
39 |
> stablereq; I guess I'm not asking a long and difficult task. |
40 |
|
41 |
what i dislike in this approach is that arch testers will follow a |
42 |
test plan which the maintainer has obviously tested before and knows |
43 |
it works. |
44 |
sending people into the jungle of 'try to do something with $pkg' may |
45 |
make them encounter problems the maintainer hadnt thought about. |
46 |
|
47 |
Regards, |
48 |
|
49 |
Alexis. |