1 |
Maurice van der Pot wrote: |
2 |
> It's understandable that fixing this is a low priority thing, but what |
3 |
> I would like to propose is to either fix the tests or disable them. |
4 |
> The latter would be the thing to do for devs who are currently closing |
5 |
> bugs about tests with WONTFIX or similar. |
6 |
> |
7 |
> If fixing the tests is not WONTFIX but rather something way down on your |
8 |
> todo list, I would also recommend disabling the tests in the ebuild. |
9 |
> A bug report could be used to track these bugs, but at least it would |
10 |
> not bother so many people while it is still unsolved. |
11 |
|
12 |
Well, in my experience as a user that has made it a priority to report |
13 |
broken test suites when I come across them (w/ patches attached whenever |
14 |
I can), I would argue that if you take the maintainers that close test |
15 |
failures as WONTFIX, and add to them the maintainers who don't care one |
16 |
way or another, and have them all disable test in their packages, you |
17 |
might as well not even have the test feature at all. :P |
18 |
|
19 |
> By keeping tests that fail enabled in one ebuild, perfectly good tests |
20 |
> of any other ebuild are rendered useless because it becomes almost |
21 |
> impossible to upgrade a system with "test" in FEATURES. |
22 |
|
23 |
It's not so bad. I keep a running list of which packages fail their |
24 |
tests on me and it's usually under half a dozen at any given time. I |
25 |
have about another half dozen open in bugzilla but most of them have |
26 |
patches included. |
27 |
|
28 |
I can definitely understand why test failures are a low-priority thing. |
29 |
They're a pain in the ass and it's not like you need yet another thing |
30 |
to maintain. But IMHO it's better to leave them enabled for some sap |
31 |
like me to fix one day down the line than to disable them now and lose |
32 |
that opportunity. |
33 |
|
34 |
Maybe a way of lessening the annoyance of test failures would be having |
35 |
a way to resume the build at the install phase. I'm thinking of |
36 |
something similar the touch ${BUILDDIR}/.compiled trick. as it is, if |
37 |
you remove test from FEATURES, touch .tested, and then 'ebuild |
38 |
foo.ebuild install' the tests still run. This is especially frustrating |
39 |
when you've just spent 6 hours compiling a package to have it fail |
40 |
because of sandboxing. |
41 |
|
42 |
--de. |
43 |
|
44 |
-- |
45 |
gentoo-dev@g.o mailing list |