| 1 |
On 3/21/11 11:02 PM, Ryan Hill wrote: |
| 2 |
> It does to me, I use them all the time. ;) The important part is that we |
| 3 |
> install the test results, which can then be used for regression testing when |
| 4 |
> rolling patchsets. |
| 5 |
|
| 6 |
I see, it makes sense. I guess you're comparing the test results before |
| 7 |
and after rolling patchsets and look for regressions. |
| 8 |
|
| 9 |
> I think that glibc and gcc tests and other testsuites that nearly always |
| 10 |
> fail shouldn't be run for the average user but should still be easily |
| 11 |
> accessible in a standard way. I think we need a more finely grained test |
| 12 |
> setup, where we can say tests are "expensive" or "interesting only to |
| 13 |
> developers" or "known to fail", and let people opt-in to these on a |
| 14 |
> per-package basis. Right now you always have to opt-out using |
| 15 |
> package.use.mask which "works" but is unintuitive. |
| 16 |
|
| 17 |
My main point is that the developer profile has FEATURES=test, and also |
| 18 |
arch testers and developers run with FEATURES=test. Being able to |
| 19 |
quickly rebuild gcc, glibc and others is a win. |
| 20 |
|
| 21 |
I'm trying to understand the problem better - do you know what causes |
| 22 |
those test failures? I don't expect a "complete" answer because that'd |
| 23 |
probably be a half of actually fixing the failures. |
Archives