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-ssh/
>>>>>>> >> > - 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
>>>>
>>>
>>>
>>
>>
>>
>
