What is the system you use?
AFAIK Esteban is fixing the latest Iceberg because it stopped to work on
Windows...

-- Pavel

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

Reply via email to