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. p.s. It would be interesting if we could get a github-style commit network graph derived from mcz files. cheers -ben
