1 |
On Sun, 12 Apr 2020 10:43:07 +0200 |
2 |
Agostino Sarubbo <ago@g.o> wrote: |
3 |
|
4 |
> In case of 'yes', the arch team member must compile with FEATURE="test" and he |
5 |
> is allowed to block the stabilization in case of test-failure. |
6 |
> |
7 |
> In case there will be a test-failure there are two choices: |
8 |
> 1) The maintainer fixes the test failure; |
9 |
> 2) The maintainer does not want to take care, so he can simply remove the |
10 |
> blocker and set "src_test pass" to no. |
11 |
> |
12 |
> Both of the above are fine for me. |
13 |
> |
14 |
> Obviously, if there are already test-failure bugs open, the flag "src_test |
15 |
> pass" should be set to 'no' when the stabilization bugs is filled. |
16 |
> |
17 |
> I'm sure that this way would help to avoid wasting time on both sides. |
18 |
> |
19 |
> What do you think about? |
20 |
|
21 |
Agree mostly, but this problem is in two places. |
22 |
|
23 |
Ebuilds themselves need more mechanisms to communicate this, as if an |
24 |
ebuild has problematic tests, then they're likely to be problematic |
25 |
every time, and remembering to set the appropriate bugzilla flags |
26 |
becomes a weakness. |
27 |
|
28 |
In this vein, there's lots of similar inadequacies you find if you |
29 |
follow this thread. |
30 |
|
31 |
Like for instance, I maintain a lot of packages where the ability for |
32 |
the tests to work is *environment specific*, and there's ultimately |
33 |
different *kinds* of testing, and the audiences who run each varies. |
34 |
|
35 |
Take perl packages for instance. There's a few where the test suite |
36 |
*cannot* work, because they need either network IO or access to |
37 |
physical devices to function. |
38 |
|
39 |
But simply disabling tests because of this produces a gross weakness, |
40 |
because Perl code cannot even be considered to be compatible with the |
41 |
target perl until you actually execute it, because those |
42 |
incompatibilities are ultimately "compiler errors", and you only see |
43 |
them when you spin up a runtime, unlike code with a dedicated compile |
44 |
stage. |
45 |
|
46 |
Subsequently, I've taken to bolting on ebuild-internal hacks that |
47 |
simply enumerate the modules and forces a perl instance to try loading |
48 |
them, to at least provide *some* degree of assurance that the code |
49 |
*probably* works. |
50 |
|
51 |
But ultimately this means the way I see it, every ebuild could have |
52 |
*multiple* test targets, and could have a control variable indicating |
53 |
which targets to execute by default, and consumer knobs could expand, |
54 |
or reduce, the testing based on preference. |
55 |
|
56 |
We could even have something like say: |
57 |
|
58 |
TEST_TARGETS="+build integration" |
59 |
TEST_RESTRICT="network-sandbox? ( !root? ( integration ))" |
60 |
|
61 |
|
62 |
Things like say, mysql, which has a standard test suite that takes days |
63 |
to run, might be well served by having controls like this, so consumers |
64 |
who want to have *some* basic assurance code works, without paying the |
65 |
price for a comprehensive smoke, can do so, instead of opting to choose |
66 |
"tests are hard, lets not do them". |
67 |
|
68 |
Just I've been cautious about talking about this, because this is such |
69 |
a can of worms, and leads into the debate about TDEPEND, and how we |
70 |
stuff everything into USE flags... |
71 |
|
72 |
And I really would *hate* for testing control variables to be USE |
73 |
flags, where --changed-use rampantly introduces unnecessary havoc |
74 |
|
75 |
( And the eventual fact will be there will be code that tries to depend |
76 |
on specific values of these test control flags, and code that wants to |
77 |
omit dependencies based on them, and portage complexity goes cray cray ) |