1 |
On Mon, 7 Jun 2010 14:02:50 +0200 |
2 |
Jeroen Roovers <jer@g.o> wrote: |
3 |
|
4 |
> I see more and more calls for either 1) "fixing the test suite", as if |
5 |
> that is suddenly not an UPSTREAM issue but the ebuilds' maintainers' |
6 |
|
7 |
> When instead a test suite should do a SKIP but erroneously does a FAIL, |
8 |
> then RESTRICT=test is not the solution. Fixing the test suite is, but |
9 |
> then that's not the maintainer's problem, but upstream's. Oddly enough |
10 |
> we have QA checks in place (for ICEs, for instance) that direct users |
11 |
> directly to upstream (through the HOMEPAGE variable), when it's |
12 |
> suddenly the maintainer's problem if a package fails its test suite |
13 |
> (because of FEATURES=userpriv or a missing kernel feature, perhaps - |
14 |
> nothing the maintainer can prepare the user's system for). |
15 |
|
16 |
I'm having trouble understanding how you can say fixing build failures is |
17 |
part of a maintainer's duties while fixing test failures is upstream's |
18 |
problem. A test failure _is_ a build failure. Yes, we should get it fixed |
19 |
upstream, just like any other bug. Packages can fail to compile with |
20 |
userpriv or missing kernel features too. Should we also send users directly |
21 |
to upstream in these cases? Can you explain the difference? |
22 |
|
23 |
I agree fully with all your other points. |
24 |
|
25 |
|
26 |
-- |
27 |
fonts, there's a hole in my neighbourhood |
28 |
gcc-porting, down which of late i cannot help but fall |
29 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |