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 ?
>
>
> 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
>>>
>>
>>
>
>
>
crash.dmp
Description: Binary data
