Re: [Pharo-dev] [regression reporter]regression occurred
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
Hi, It is already fixed and will be integrated with GT 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 25 Feb 2015, at 16:04, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
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 Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe" <sven@stfx.eu <mailto:sven@stfx.eu>> wrote: Number>>#brickValue: must die !
On 25 Feb 2015, at 15:53, no-reply@ci.inria.fr <mailto:no-reply@ci.inria.fr> wrote:
https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label... <https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label...>
1 regressions found. KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
Hi,
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.
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. :) Cheers, Alex 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:
Hi,
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 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
The next integration will happen tomorrow. Andrei is preparing it. Doru -- www.tudorgirba.com "Every thing has its own flow"
On 25 Feb 2015, at 16:11, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
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.
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. :)
Cheers, Alex
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:
Hi,
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 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 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
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
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 <sven@stfx.eu> wrote:
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
On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
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.
In 40 update #520 Marcus
Thanks :) We would still want to do one more update, maybe today or tomorrow, to add the extension for recording user data. Afterwards it's bug fixing mode. On Fri, Feb 27, 2015 at 5:37 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
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.
In 40 update #520
Marcus
On Fri, Feb 27, 2015 at 6:03 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
Thanks :) We would still want to do one more update, maybe today or tomorrow, to add the extension for recording user data.
The last update for GTools that adds a bigger features is ready for review: https://pharo.fogbugz.com/f/cases/15018/Integrate-GT-tools-with-event-recode... Cheers, Andrei
Afterwards it's bug fixing mode.
On Fri, Feb 27, 2015 at 5:37 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis <chisvasileandrei@gmail.com
wrote:
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.
In 40 update #520
Marcus
Thank you! Doru On Fri, Feb 27, 2015 at 5:37 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
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.
In 40 update #520
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
participants (6)
-
Aliaksei Syrel -
Andrei Chis -
Ben Coman -
Marcus Denker -
Sven Van Caekenberghe -
Tudor Girba