- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Henrik Johansen

On Aug 8, 2013, at 3:03 , Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 August 2013 14:14, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> I guess that solves the question around the fate of the cog issue tracker: I >> didn't mean a deprecation or similar, people can continue using it as they >> want. I put for that links so people can go back and forth between the issue >> trackers. My unique and good intention was to make those issues more >> visible. > > Thanks, Guillermo. > I think everyone understands that your intention was for good, but > when you don't inform > people properly they tend to think worst (including me) > > :) > > -- > Best regards, > Igor Stasenko. > Especially when you end up spamming VM-dev with Cog issue tracker updates saying "Moved to fogbugz". Even with the modified updates, why you'd need to mirror an existing tracker for a related but distinct project into the Pharo tracker, with the synchronization issues that might cause, js still a bit beyond me. Cheers, Henry

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Andres Valloud

Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and that consequently the Pharo VM as compiled won't run on any Linux distro older than 17 months? On 8/8/13 5:52 , Igor Stasenko wrote: > Yes. It is known issue. > Now there's little we can do, except from building VM for debian > platform separately. > > On 8 August 2013 11:43, Laszlo Zsolt Kiss <lzskiss(a)dublin.ie> wrote: >> Hi. >> >> The latest Pharo VM isnt working on Debian 7. >> >> The error message: >> >> /work/pharo3.0/bin/pharo: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version >> `GLIBC_2.15' not found >> >> The Glibc version in Debian 7 is 2.13. >> >> Best regards >> >> Laszlo Zsolt KIss >> >> > > >

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

On 8 August 2013 13:35, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 8 Aug 2013, StÃ©phane Ducasse wrote: > >> >> On Aug 7, 2013, at 8:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Well, my intent was to keep working together on it and be as open as >>> possible to >>> people who may not work particularly on Pharo, but care/use Cog. >>> >>> >>> Now my dilemma is, what is the fate of Cog tracker? >>> >>> On 7 August 2013 20:29, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>>> >>>> I think that's not true at all. >>>> >>>> Our git repo and our vmmaker repo are used to build only the pharo vm >>>> flavor. If we make a fix it does not get magically integrated into >>>> eliots >>>> cog. >>>> >>> >>> Guillermo , it is not 'our' and never been. It belongs to community, >>> and Pharo is just part of it. >>> I had hard time convincing people to join and use git and tracker.. >>> Now this move puts a big cross on all these efforts. >>> >>> >>> Of course i understand the benefits of having everything at one place. >>> And of course we (as Pharo team) are free to organize own work in a >>> way we see fit. >> >> >> indeed but do not see the devil everywhere >> why putting the issue on a public tracker means private? > > > How is that a "public tracker"? > can you elaborate? https://pharo.fogbugz.com/ is publicly accessible, no? or what makes you think it is not public? > > Levente > > >> >>> But i don't think we will find understanding if we start privatizing >>> things which are not belong to us. >>> Because initially this stuff was created without intent to be >>> 'pharo-only' or for 'pharo-only'. >> >> >> >> You see that clement is implementing clean blocks and that eliot wants to >> integrate his work in COG. >> >> >> Stef >> >>> >>>> Maybe they can benefit from the changes but they have to merge back as >>>> you >>>> esteban and igor merge in our branch. >>>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

On 8 August 2013 14:14, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I guess that solves the question around the fate of the cog issue tracker: I > didn't mean a deprecation or similar, people can continue using it as they > want. I put for that links so people can go back and forth between the issue > trackers. My unique and good intention was to make those issues more > visible. Thanks, Guillermo. I think everyone understands that your intention was for good, but when you don't inform people properly they tend to think worst (including me) :) -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Igor Stasenko

Yes. It is known issue. Now there's little we can do, except from building VM for debian platform separately. On 8 August 2013 11:43, Laszlo Zsolt Kiss <lzskiss(a)dublin.ie> wrote: > Hi. > > The latest Pharo VM isnt working on Debian 7. > > The error message: > > /work/pharo3.0/bin/pharo: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version > `GLIBC_2.15' not found > > The Glibc version in Debian 7 is 2.13. > > Best regards > > Laszlo Zsolt KIss > > -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Guillermo Polito

I sent this mail to the vm mailing list: "I mirrored the issues from the cog issue tracker inside the pharo one, so they have more visibility for people only working the pharo issue tracker. Issues in both trackers have a link pointing to its pair, in case someone wants to do the follow up. In any case, my idea was to enhance visibility and use one tool for all issues, not to deprecate either issue tracker. In the meanwhile I saw there are many issues that are probably already integrated, others that probably deserve to have a look and integrate them :). And of course, I realized that I the issue tracker spammed seriously this list. I apologize for that! Best, Guille" I guess that solves the question around the fate of the cog issue tracker: I didn't mean a deprecation or similar, people can continue using it as they want. I put for that links so people can go back and forth between the issue trackers. My unique and good intention was to make those issues more visible. On Thu, Aug 8, 2013 at 1:35 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 8 Aug 2013, StÃ©phane Ducasse wrote: > > >> On Aug 7, 2013, at 8:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Well, my intent was to keep working together on it and be as open as >>> possible to >>> people who may not work particularly on Pharo, but care/use Cog. >>> >>> >>> Now my dilemma is, what is the fate of Cog tracker? >>> >>> On 7 August 2013 20:29, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> >>>> I think that's not true at all. >>>> >>>> Our git repo and our vmmaker repo are used to build only the pharo vm >>>> flavor. If we make a fix it does not get magically integrated into >>>> eliots >>>> cog. >>>> >>>> >>> Guillermo , it is not 'our' and never been. It belongs to community, >>> and Pharo is just part of it. >>> I had hard time convincing people to join and use git and tracker.. >>> Now this move puts a big cross on all these efforts. >>> >>> >>> Of course i understand the benefits of having everything at one place. >>> And of course we (as Pharo team) are free to organize own work in a >>> way we see fit. >>> >> >> indeed but do not see the devil everywhere >> why putting the issue on a public tracker means private? >> > > How is that a "public tracker"? > > > Levente > > > >> But i don't think we will find understanding if we start privatizing >>> things which are not belong to us. >>> Because initially this stuff was created without intent to be >>> 'pharo-only' or for 'pharo-only'. >>> >> >> >> You see that clement is implementing clean blocks and that eliot wants to >> integrate his work in COG. >> >> >> Stef >> >> >>> Maybe they can benefit from the changes but they have to merge back as >>>> you >>>> esteban and igor merge in our branch. >>>> >>>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >>

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Levente Uzonyi

On Thu, 8 Aug 2013, StÃ©phane Ducasse wrote: > > On Aug 7, 2013, at 8:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Well, my intent was to keep working together on it and be as open as possible to >> people who may not work particularly on Pharo, but care/use Cog. >> >> >> Now my dilemma is, what is the fate of Cog tracker? >> >> On 7 August 2013 20:29, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> I think that's not true at all. >>> >>> Our git repo and our vmmaker repo are used to build only the pharo vm >>> flavor. If we make a fix it does not get magically integrated into eliots >>> cog. >>> >> >> Guillermo , it is not 'our' and never been. It belongs to community, >> and Pharo is just part of it. >> I had hard time convincing people to join and use git and tracker.. >> Now this move puts a big cross on all these efforts. >> >> >> Of course i understand the benefits of having everything at one place. >> And of course we (as Pharo team) are free to organize own work in a >> way we see fit. > > indeed but do not see the devil everywhere > why putting the issue on a public tracker means private? How is that a "public tracker"? Levente > >> But i don't think we will find understanding if we start privatizing >> things which are not belong to us. >> Because initially this stuff was created without intent to be >> 'pharo-only' or for 'pharo-only'. > > > You see that clement is implementing clean blocks and that eliot wants to integrate his work in COG. > > > Stef > >> >>> Maybe they can benefit from the changes but they have to merge back as you >>> esteban and igor merge in our branch. >>> >> >> -- >> Best regards, >> Igor Stasenko. >> > > >

Aug. 8, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 7 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testNotEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testOrEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testRemoveSelectorByAndAndNot Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

Aug. 8, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 7 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testNotEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testOrEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testRemoveSelectorByAndAndNot Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

Aug. 8, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 7 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testNotEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testOrEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testRemoveSelectorByAndAndNot Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

Aug. 8, 2013