The issue is waiting integration: https://pharo.fogbugz.com/f/cases/14993/Integrate-GTools There are still some more bugs to fix but we should integrate nevertheless.
Cheers, Andrei On Thu, Feb 26, 2015 at 3:46 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > On 26 Feb 2015, at 15:35, Ben Coman <b...@openinworld.com> wrote: > > > >> On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe" <s...@stfx.eu> wrote: > >> Number>>#brickValue: must die ! > >> > >> > On 25 Feb 2015, at 15:53, no-re...@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.den...@inria.fr> > wrote: > > > >> On 25 Feb 2015, at 16:04, Aliaksei Syrel <alex.sy...@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.sy...@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. > > I think that in certain cases (something urgent, something really > annoying) it would be OK to patch it directly. It is then up to the > external package maintainers to pick up the change up stream. > > Working with components/modules should not limit what we do. > > Of course, for new features this would not be OK. > > > p.s. It would be interesting if we could get a github-style commit > network graph derived from mcz files. > > > > cheers -ben > > > > >
