On 26 Feb 2015, at 15:35, Ben Coman <btc@openInWorld.com> wrote:
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.
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