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...
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