[Pharo-dev] [regression reporter]regression occurred

Camillo Bruni camillobruni at gmail.com
Mon Oct 21 18:14:02 EDT 2013

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 at 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 at gmail.com> wrote:
>> sad but true :(
>> On 2013-10-21, at 08:37, Marcus Denker <marcus.denker at 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 at ci.inria.fr wrote:
>>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/label=win/21/
>>>> 2 regressions found.
>>>> Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits
>>>> Zinc.Tests.ZnServerTests.testEntityTooLarge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 447 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131022/cf41c5ac/attachment.asc>

More information about the Pharo-dev mailing list