Hey, is it possible to integrate updates to external projects (like Renraku) into Pharo 7?
Uko > On 10 Jul 2017, at 22:01, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com > <mailto:nicolaih...@gmail.com>>: > > > 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com > <mailto:esteba...@gmail.com>>: > >> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaih...@gmail.com >> <mailto: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 > <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 > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $ > > > > > > > >> >> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" <pavel.kriva...@gmail.com >> <mailto:pavel.kriva...@gmail.com>>: >> >> >> 2017-06-28 17:06 GMT+02:00 Clément Bera <bera.clem...@gmail.com >> <mailto: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 >> <mailto:b...@openinworld.com>> wrote: >> >> >> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kube...@icloud.com >> <mailto:juraj.kube...@icloud.com>> wrote: >> >>> El 28-06-2017, a las 02:57, Ben Coman <b...@openinworld.com >>> <mailto:b...@openinworld.com>> escribió: >>> >>> >>> >>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.kriva...@gmail.com >>> <mailto:pavel.kriva...@gmail.com>> wrote: >>> >>> >>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckw...@gmail.com >>> <mailto:serge.stinckw...@gmail.com>>: >>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>> <pavel.kriva...@gmail.com <mailto:pavel.kriva...@gmail.com>> wrote: >>> > >>> > >>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckw...@gmail.com >>> > <mailto:serge.stinckw...@gmail.com>>: >>> >> >>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>> >> <pavel.kriva...@gmail.com <mailto: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-ssh/ >>> >> > <https://help.github.com/articles/connecting-to-github-with-ssh/> >>> >> > - create own pharo-project/pharo repository fork. Go to >>> >> > https://github.com/pharo-project/pharo >>> >> > <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 >>> >> > <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/ >>> <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-automatically-create-bug-events-with-commits/ >> >> <https://blog.fogcreek.com/improved-github-integration-automatically-create-bug-events-with-commits/> >> >> >> cheers -ben
