On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe" <sven@stfx.eu> wrote:
Number>>#brickValue: must die !

> On 25 Feb 2015, at 15:53,��no-reply@ci.inria.fr��wrote:
>
>��https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
>
> 1 regressions found.
>�� KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses



On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker��<marcus.denker@inria.fr>��wrote:

On 25 Feb 2015, at 16:04, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

It is already fixed and will be integrated with GT

When will this happen? this test fails since *WEEKS*, yet I could have fixed it in 5 minutes. But I can���t.
We make ourselves completely powerless. This does not make me feel good.��
��
On Wed, Feb 25, 2015 at 11:11 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

Normally GT should be released more often. This time while Jenkins was down we did a lot of changes and now it takes some time to prepare everything for integration. Also at the moment of previous release moose didn't run tests like BehaviourTest and others. :)



Thats a fair reason, but philosophically we still have a feature branch holding up a bug fix, because we have a a single-branch workflow. �� Consider a future where Pharo has more external packages, where a hypothetical package (with less diligent developers than GT) has a longer feature development cycle.�� Should bug fixes be held up?�� Or should external packages have a bug-fix-branch and a feature-development-branch - with a workflow where before the feature-development-branch is integrated, it merges in any bug-fix-branch commits.

p.s. It would be interesting if we could get a github-style commit network graph derived from mcz files.

cheers -ben��