> On 26 Feb 2015, at 15:35, Ben Coman <[email protected]> wrote: > >> On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe" <[email protected]> wrote: >> Number>>#brickValue: must die ! >> >> > On 25 Feb 2015, at 15:53, [email protected] 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 <[email protected]> wrote: > >> On 25 Feb 2015, at 16:04, Aliaksei Syrel <[email protected]> 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 <[email protected]> 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 >
