1 |
On Mon, 29 Dec 2003 04:00:40 +0000 |
2 |
Tom Payne <twp@g.o> wrote: |
3 |
|
4 |
> Problems solved: |
5 |
> |
6 |
> Arch leads no longer have to test every single ebuild that comes there |
7 |
> way-- non x86 arches get package updates quicker with reduced workload |
8 |
> for arch leads. |
9 |
|
10 |
If we can do this without a loss of the Q in QA, then I'm all for it :) |
11 |
|
12 |
One alternative that is becoming available to developers are the |
13 |
development/release engineering boxes that are cropping up. |
14 |
|
15 |
For a lot of programs out there, it's not hard to test their functionality |
16 |
remotely (though GUI applications can be a bit harder). I imagine having |
17 |
one or two people per herd with accounts on these various boxes would help |
18 |
improve QA substantially. |
19 |
|
20 |
Granted at the current time, not all arches have a publically |
21 |
available test machine or two, but it definitely decreases the |
22 |
amount of work on the arch devs and the "no news is good news" |
23 |
stablization of ebuilds that happens now. |
24 |
|
25 |
> No need to write unit tests for packages to help arch leads (lots of |
26 |
> work and hard to do in some cases (e.g. interactive progs)). |
27 |
|
28 |
Test cases don't necessarily need to be automated. A simple list of |
29 |
instructions to verify functionality that a dev could run wound be |
30 |
acceptable (to me). |
31 |
|
32 |
For example |
33 |
|
34 |
1) Do operation a |
35 |
2) Do operation b |
36 |
3) Expect result c |
37 |
|
38 |
> New problems: |
39 |
> |
40 |
> Might result in broken software being installed. |
41 |
|
42 |
I'd like to avoid this if at all possible. All software in the tree, |
43 |
even if it's marked ~arch, is supposed to work. The fact that ~arch |
44 |
things are broken is bad, but if a package gets to arch broken or still |
45 |
broken is even worse, and reflects poorly on Gentoo as a whole. |
46 |
|
47 |
> Feedback please. I advocate this approach for 'minor' packages, i.e. |
48 |
> nothing fundamental to the working of the system. It's more suitable for |
49 |
> scripting language libraries and minor applications (e.g. obscure window |
50 |
> managers). |
51 |
|
52 |
While most of the time, packages aren't problematic on non-x86 arches, |
53 |
there do crop up those that have abnormal behavior. Whether it's unable |
54 |
to compile or has undesired/broken functionality once compiled/installed. |
55 |
|
56 |
I'm a bit more open to packages that are scripts, but I have yet to meet a |
57 |
language that is truly as cross-platform compatible as they all claim to |
58 |
be (not that I'm any kind of official reviewer or have run into every |
59 |
language out there). |
60 |
|
61 |
However, if something like this is implemented, I would ask that programs |
62 |
that need to be compiled not be put into this list. If a problem is going |
63 |
to crop up, it'll be here, and often times Makefiles don't fail correctly |
64 |
if something cannot build (for instance try over-optimizing |
65 |
net-firewall/fwbuilder and then find the fwbuilder executable after it has |
66 |
installed). |
67 |
|
68 |
|
69 |
My (non-refundable) $0.02, |
70 |
-- |
71 |
Jason Wever |
72 |
Gentoo/Sparc Team Co-Lead |