sad but true :( On 2013-10-21, at 08:37, Marcus Denker <marcus.denker@inria.fr> wrote:

I have turned off these emails for now, they are too many and thus get ignored (I have never seen anyone but me filing an issue tracker entry for a newly failing test…)

Marcus

On Oct 21, 2013, at 8:32 AM, no-reply@ci.inria.fr wrote:

...

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/label...

2 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits Zinc.Tests.ZnServerTests.testEntityTooLarge

The idea would be that the whole integration fails with only a single test failing. But for that the monkey has to be at 100% ;) and we're at 95% or so and only integrate a single issue at a time and then rerun all validations, but thats future talk. For now, I think the only reasonable thing is to look at the build each friday and make it green, since classifying tests is not that easy, and the jenkins setup is already close to be unmaintainable. On 2013-10-21, at 23:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Tests that fail indicate that something is broken. They are like a kind of todo. But sometimes they are hard to fix and remain open for a long time. I understand that that conflicts with the notion of being 'all green all the time'. Maybe we should classify them somehow ?

On 21 Oct 2013, at 23:08, Camillo Bruni <camillobruni@gmail.com> wrote:

...

sad but true :(

On 2013-10-21, at 08:37, Marcus Denker <marcus.denker@inria.fr> wrote:

...

I have turned off these emails for now, they are too many and thus get ignored (I have never seen anyone but me filing an issue tracker entry for a newly failing test…)

Marcus

On Oct 21, 2013, at 8:32 AM, no-reply@ci.inria.fr wrote:

...

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/label...

2 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits Zinc.Tests.ZnServerTests.testEntityTooLarge