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