On Monday 09 of March 2009 22:36:33 Ciaran McCreesh wrote: > On Mon, 9 Mar 2009 22:33:11 +0100 > > Christian Faulhammer <fa...@gentoo.org> wrote: > > Ciaran McCreesh <ciaran.mccre...@googlemail.com>: > > > Next, some probably easy but long standing features: > > > > > > * src_test run unless RESTRICTed or explicitly disabled by the user > > > (bug 184812) > > > > A big no. This will lead to many failures on user systems, people > > who run stable will be greatly annoyed. I know this is inspired by > > good intentions, but will not have the desired effect. > > People who run stable won't see test failures, because developers and > arch testers and ~arch users will all have run the tests already and > made sure there aren't any failures. And if there *are* failures that > make it past all three levels of checking before stable, they really > need to be investigated -- chances are they're showing a legitimate > problem.
Unfortunately upstream tends to think of tests in very relaxed way. Some critical packages, like openssl are thoroughly tested for regressions and are already supplied with complete unit test modules. There's unfortunately the problem with let's call them "desktop" packages, where having test suite compile at all (not talking about running it successfully) can be considered luck. What are packagers supposed to do in such case? - hold the package in stasis in some overlay and push upstream to fix the issue they're probably not willing/understaffed to - when fixed - push to tree? - fix test suit by themselves? - RESTRICT=test in affected package? It all depends on what one tries to achieve. I'm quite certain that user of average distribution (even source based) is not particularly interested in *actively* participating in software testing process with all consequences like not getting something built just because some minor unit test failed for him. That kind of package maintenance should be left *only* for packagers imho (if not taken care of upstream developers already). Also the problem is with numbers - such global change (like enabling src_test stage for every package by default unless restricted) will immediately affect all packages in tree. Thus I wouldn't recommend converting user environments into tinderbox. -- regards MM
signature.asc
Description: This is a digitally signed message part.
