2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
> What is the system you use? > AFAIK Esteban is fixing the latest Iceberg because it stopped to work on > Windows... > > -- Pavel > windows 10 32 bit > > 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: > >> >> >> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: >> >>> >>> >>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>: >>> >>>> >>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com> wrote: >>>> >>>> And if I only want to contribute by reviewing a fix. Do I have to go >>>> the git-path ? >>>> Or is there a way to just start up an image and load and review the >>>> change? >>>> >>>> >>>> right now, you can review by going to github and seeing. >>>> I will add a “PR tool” to view/load PRs into an image, but that’s not >>>> ready. If someone wants to take a hit on it… the idea is to extend the >>>> github plugin with it :) >>>> >>>> cheers! >>>> Esteban >>>> >>> >>> Anyone got this working on windows (32) ? >>> I followed this guide, enabled the ssh key setting for iceberg. >>> But I still got the error : >>> >>> Image: Pharo7.0SNAPSHOT [Latest update: #0] >>> >>> LGitReturnCodeEnum>>handleLGitReturnCode >>> Receiver: a LGitReturnCodeEnum(#git_error [-1]) >>> Arguments and temporary variables: >>> handler: LGit_GIT_ERROR >>> Receiver's instance variables: >>> value: -1 >>> >>> >>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo: >>> Receiver: a LGitRepository (<not initialized>) >>> Arguments and temporary variables: >>> callBlock: [ self >>> clone: self >>> url: aString >>> local_path: aFileReference pathSt...etc... >>> Receiver's instance variables: >>> handle: @ 16r00000000 >>> repositoryPath: File @ pharo-core >>> isOpen: nil >>> workingDirectory: nil >>> >>> >>> LGitRepository>>clone:options:to: >>> Receiver: a LGitRepository (<not initialized>) >>> Arguments and temporary variables: >>> aString: 'g...@github.com:pharo-project/pharo.git' >>> cloneOptions: a LGitCloneOptions () >>> aFileReference: File @ pharo-core >>> Receiver's instance variables: >>> handle: @ 16r00000000 >>> repositoryPath: File @ pharo-core >>> isOpen: nil >>> workingDirectory: nil >>> >>> >>> And finally after some more tries, the vm crashed >>> (crash.dmp attached). >>> >>> If this only happens on windows, what else would be an option to start >>> with contributing for pharo 7 ? >>> >> >> maybe I am doing something wrong ? I thought this should work now with >> the latest vm (and libgit)? >> It is still crashing for me. >> >> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed >> [0mExternalAddress class(Object)>>primitiveFailed: >> ExternalAddress class(Object)>>primitiveFailed >> ExternalAddress class>>allocate: >> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >> LGitRemoteCallbacks class>>defaults >> LGitRemoteCallbacks class>>withProvider: >> LGitCloneOptions class>>withCredentialsProvider: >> [ | repo cloneOptions | >> repo := LGitRepository on: self location. >> cloneOptions := LGitCloneOptions >> withCredentialsProvider: IceCredentialsProvider default. >> repo clone: url options: cloneOptions. >> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >> (LGitRemote of: repo named: 'origin') >> lookup; >> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >> in Block: [ | repo cloneOptions |... >> [ self checkInitialized. >> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class failed >> [0mExternalAddress class(Object)>>primitiveFailed: >> ExternalAddress class(Object)>>primitiveFailed >> ExternalAddress class>>allocate: >> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >> LGitRemoteCallbacks class>>defaults >> LGitRemoteCallbacks class>>withProvider: >> LGitCloneOptions class>>withCredentialsProvider: >> [ | repo cloneOptions | >> repo := LGitRepository on: self location. >> cloneOptions := LGitCloneOptions >> withCredentialsProvider: IceCredentialsProvider default. >> repo clone: url options: cloneOptions. >> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >> (LGitRemote of: repo named: 'origin') >> lookup; >> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >> in Block: [ | repo cloneOptions |... >> [ self checkInitialized. >> aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self >> checkInitialized.... >> [ activeProcess psValueAt: index put: anObject. >> aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in >> Block: [ activeProcess psValueAt: index put: anObject.... >> BlockClosure>>ensure: >> LGitActionSequence(DynamicVariable)>>value:during: >> LGitActionSequence class(DynamicVariable class)>>value:during: >> LGitGlobal class>>runSequence: >> IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >> IceRepositoryCreator>>createRepository >> UndefinedObject>>DoIt >> >> VM windows 32 bit: >> CoInterpreter VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c >> Jul 10 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 >> VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> >> >> >> >>> >>> >>> >>>> >>>> >>>> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < >>>> pavel.kriva...@gmail.com>: >>>> >>>> >>>> >>>> 2017-06-28 17:06 GMT+02:00 Clément Bera <bera.clem...@gmail.com>: >>>> >>>>> Hi all, >>>>> >>>>> Just to be clear, in Pharo 7, if I want to get some code integrated: >>>>> - I *have to* use the pull request process described by Pavel >>>>> OR >>>>> - I *can* use the pull request process, but I can also use the old >>>>> slice monticello process >>>>> ? >>>>> >>>>> What is the answer to the first question now, and what will be the >>>>> answer of this question in 6 months from now ? >>>>> >>>> >>>> You should use the pull request process. >>>> >>>> It is possible to create a standard slice BUT it must be done from >>>> Pharo 6 and then sent into Pharo60Inbox. And then you need to wait until >>>> somebody converts this slice to pull request. That means that it will be >>>> harder and harder to contribute this way because the code-base is moving. >>>> >>>> No slice will be integrated into Pharo 7 with the old process directly. >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <b...@openinworld.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < >>>>>> juraj.kube...@icloud.com> wrote: >>>>>> >>>>>>> >>>>>>> El 28-06-2017, a las 02:57, Ben Coman <b...@openinworld.com> >>>>>>> escribió: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>>>>>> pavel.kriva...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich < >>>>>>>> serge.stinckw...@gmail.com>: >>>>>>>> >>>>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>>>>> <pavel.kriva...@gmail.com> wrote: >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>>>>> serge.stinckw...@gmail.com>: >>>>>>>>> >> >>>>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>>>>> >> <pavel.kriva...@gmail.com> wrote: >>>>>>>>> >> > Hi, >>>>>>>>> >> > >>>>>>>>> >> > this mail describes how to start to send pull requests to >>>>>>>>> Pharo 7 Github >>>>>>>>> >> > repository from Pharo 7. >>>>>>>>> >> >>>>>>>>> >> Thank you for the great explanation Pavel. >>>>>>>>> >> >>>>>>>>> >> > Preparations >>>>>>>>> >> > ===================== >>>>>>>>> >> > >>>>>>>>> >> > - you need to have a Github account and set SSH keys. See >>>>>>>>> >> > https://help.github.com/articles/connecting-to-github-with-s >>>>>>>>> sh/ >>>>>>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>>>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" >>>>>>>>> button and >>>>>>>>> >> > follow >>>>>>>>> >> > the instructions >>>>>>>>> >> >>>>>>>>> >> [ ... ] >>>>>>>>> >> >>>>>>>>> >> > Issue processing >>>>>>>>> >> > ===================== >>>>>>>>> >> > >>>>>>>>> >> > - create new case on FogBugz to get the issue number >>>>>>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>>>>>> repository do: >>>>>>>>> >> > Pharo >>>>>>>>> >> > - Create new branch from FogBugz issue, enter the issue ID >>>>>>>>> and it will >>>>>>>>> >> > fill >>>>>>>>> >> > the full branch name for you >>>>>>>>> >> > - create your changes (you can do it before the creation of >>>>>>>>> the branch >>>>>>>>> >> > too) >>>>>>>>> >> > - commit and push your changes in Iceberg, this way you will >>>>>>>>> commit your >>>>>>>>> >> > branch to your fork repository. Remember that the Iceberg >>>>>>>>> commit window >>>>>>>>> >> > has >>>>>>>>> >> > two buttons, one for local commit, the second for commit with >>>>>>>>> immediate >>>>>>>>> >> > push. They can be very long because they contain the full >>>>>>>>> branch (issue) >>>>>>>>> >> > name >>>>>>>>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo >>>>>>>>> - Create >>>>>>>>> >> > pull >>>>>>>>> >> > request, fill your >>>>>>>>> >> > - fill your Github credentials >>>>>>>>> >> > - leave the PR title, comment is not required, check the pull >>>>>>>>> request >>>>>>>>> >> > head >>>>>>>>> >> > and base. The base MUST be pharo-project/pharo development. >>>>>>>>> Create the >>>>>>>>> >> > pull >>>>>>>>> >> > requests >>>>>>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, check >>>>>>>>> your pull >>>>>>>>> >> > requests and put URL of it into the issue record on FogBugz >>>>>>>>> (as a >>>>>>>>> >> > comment). >>>>>>>>> >> > Resolve the issue as Fix review needed >>>>>>>>> >> >>>>>>>>> >> It means, there is no PR without a corresponding FogBugz issue ? >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Yes, at least for code changes we would like to keep this >>>>>>>>> relation. If it is >>>>>>>>> > a really trivial change in readme or something like that, we can >>>>>>>>> accept no >>>>>>>>> > related issue record. >>>>>>>>> > Please prefer to comment the issues instead of PRs directly to >>>>>>>>> have all >>>>>>>>> > information at one place. >>>>>>>>> >>>>>>>>> Thank you Pavel for the explanation. >>>>>>>>> >>>>>>>>> Maybe in the future, it will make sense to put everything in the PR >>>>>>>>> and use github issues. >>>>>>>>> You will use CI travis builds for all PR ? >>>>>>>>> >>>>>>>> >>>>>>>> For now we will use FogBugz because it has a lot of nice features >>>>>>>> and good API. Maybe we will switch it in future but now we should not >>>>>>>> change too many things at once :-) >>>>>>>> For several reasons we now prefer to use own infrastructure for >>>>>>>> checking of PRs (mainly because of MacOS issues on Travis). But again, >>>>>>>> it >>>>>>>> can be changed in future. >>>>>>>> >>>>>>>> >>>>>>> It would be interesting to see how this might fit in with our >>>>>>> workflow... >>>>>>> https://blog.fogcreek.com/fogbugz-github-integration/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> What is the benefit of the integration? I do not understand it from >>>>>>> the given link. >>>>>>> >>>>>>> >>>>>> When you submit a PR on github, Fogbugz is automatically updated with >>>>>> a link to the PR. >>>>>> Presumably this makes it easier for people reviewing cases in Fogbugz >>>>>> to identify the slice to test. >>>>>> This is a better link... >>>>>> https://blog.fogcreek.com/improved-github-integration-automa >>>>>> tically-create-bug-events-with-commits/ >>>>>> >>>>>> cheers -ben >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >
