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