It is an iceberg plugin. 100% Pharo Code, uses the github.com rest api.��

On 30 Jun 2017 09:25, "Stephane Ducasse" <stepharo.self@gmail.com> wrote:
What is the github plugin? an Iceberg Pharo code or a C plugin?

On Wed, Jun 28, 2017 at 6:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
>
> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess@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
>
>
> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek"
> <pavel.krivanek@gmail.com>:
>
>
>
> 2017-06-28 17:06 GMT+02:00 Cl��ment Bera <bera.clement@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 <btc@openinworld.com> wrote:
>>>
>>>
>>>
>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka@icloud.com>
>>> wrote:
>>>>
>>>>
>>>> El 28-06-2017, a las 02:57, Ben Coman <btc@openinworld.com> escribi��:
>>>>
>>>>
>>>>
>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek
>>>> <pavel.krivanek@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich
>>>>> <serge.stinckwich@gmail.com>:
>>>>>>
>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek
>>>>>> <pavel.krivanek@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich
>>>>>> > <serge.stinckwich@gmail.com>:
>>>>>> >>
>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek
>>>>>> >> <pavel.krivanek@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-automatically-create-bug-events-with-commits/
>>>
>>> cheers -ben
>>
>>
>
>
>