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