Hi, I've made some write up for the pharo part (not metacello or external projects) Of course, expect bugs on it :) Not everything is smooth. If you have comments, they are welcome. Guille
|
Hi Guille,
nice writeup and definitely needed. Thanks a lot! If possible you should complete it with:
- how Windows users could contribute
- that #development branch is used instead of master
- how one can keep his own fork up to date
Also it would be good to have the AboutBox in Pharo with the build number again. Because the ZeroCnnf just gives you a Pharo.image and nobody knows what the build number
or sha was to reproduce how old or new this is. Thanks
T.
Gesendet: Donnerstag, 10. August 2017 um 17:17 Uhr
Von: "Guillermo Polito" <[hidden email]> An: "Discusses Development of Pharo" <[hidden email]> Betreff: [Pharo-dev] Writeup: how to contribute to Pharo Hi,
I've made some write up for the pharo part (not metacello or external projects)
Of course, expect bugs on it :) Not everything is smooth. If you have comments, they are welcome.
Guille
|
On Thu, Aug 10, 2017 at 9:39 PM, Torsten Bergmann <[hidden email]> wrote:
Hard topic. I'm taking benefit of my gf's windows computer right now to test. Basically, windows has problems with long paths but there are workarounds. Icerberg works by default without any changes (same bugs as in linux and osx at least :)). Here are my notes to make it work: * Download latest pharo: * Clone using sourcetree This is very slow and failed to checkout (not clone) because of the "Filename too long errors" I found for this the following workaround: http://pingec.si/blog/articles/msysgit-longpath/ Once I did that, sourcetree worked nicely, and I could commit and change branches using iceberg. Warning: I did not test making changes on the "long files" to see what happens...
I'll make another writeup about the entire process.
And about this one too
Well, actually right now SystemVersion current has the hash of the commit the image was generated from if you check the inspector. It's then a UI problem and easy to fix. Maybe somebody could use this to try making a pull request? Then, we could add a build number in SystemVersion of course. Guille
|
In reply to this post by Guillermo Polito
Tx this is really good and I will use it to produce new clean images to work on Pharo 70 On Thu, Aug 10, 2017 at 5:17 PM, Guillermo Polito <[hidden email]> wrote:
|
In reply to this post by Guillermo Polito
Am 10.08.2017 11:21 nachm. schrieb "Guillermo Polito" <[hidden email]>:
What does "clone using sourcetree" mean?
|
Le 10/08/2017 à 23:58, Nicolai Hess a écrit :
> > What does "clone using sourcetree" mean? > > IIRC SourceTree is a Git GUI available on Windows, as GitKraken, SmartGit, GitExtensions, TortoiseGit… -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France signature.asc (836 bytes) Download Attachment |
Am 11.08.2017 12:02 vorm. schrieb "Cyril Ferlicot D." <[hidden email]>:
Ok, so I can just clone via command line git clone ....
|
In reply to this post by Guillermo Polito
2017-08-10 17:17 GMT+02:00 Guillermo Polito <[hidden email]>:
In option 2, I think this should be "Click on the Edit button",
|
In reply to this post by Guillermo Polito
2017-08-10 17:17 GMT+02:00 Guillermo Polito <[hidden email]>:
Maybe I mixed something up, but following the other (pavel)howto I thought that I would clone the origin repository, (and edit iceberg to use the local clone as the origin) and later define my (github)-fork as another remote. But in your screenshots, it looks like you cloned your pharo fork, and set the original pharo git project as another remote. Are both options equal and just differe in which remote is called "pharo" and which is called "origin" ?
|
Le ven. 11 août 2017 à 00:53, Nicolai Hess <[hidden email]> a écrit :
Bord are similar. If you clone pharo, you set your fork as push remote. If you clone ur fork you set pharo as pull remote. I don't remember if iceberg lets u rename a remote, but I think the remote name is not important but the URL. In any case you need both remotes. If you don't have pharo as remote you wont see the pharo plugin.
--
|
In reply to this post by Nicolai Hess-3-2
2017-08-11 0:53 GMT+02:00 Nicolai Hess <[hidden email]>:
To have pharo-project/pharo as the origin is a scheme that Esteban is using and in past Iceberg had troubles to enable Pharo pluggin correctly for repositories that were not set like that. Now it does not matter, however if you will use your local repository clone more, you will have forks of other people as remotes too and then it is quite natural to have your own fork as only one of them. -- Pavel
|
In reply to this post by Nicolai Hess-3-2
On Thu, Aug 10, 2017 at 11:58 PM, Nicolai Hess <[hidden email]> wrote:
Yeap, sorry. I meant It is a free graphical git client from atlassian. In windows I default to graphical tools :). I assume not most of the people will install a msys environment on their machines (but maybe I'm wrong...).
|
In reply to this post by Nicolai Hess-3-2
On Fri, Aug 11, 2017 at 12:34 AM, Nicolai Hess <[hidden email]> wrote:
Thanks, fixed!
|
I extended the document with some windows specific instructions also. On Fri, Aug 11, 2017 at 9:31 AM, Guillermo Polito <[hidden email]> wrote:
|
Nicolai I started super simple. I clone and point my fresh dled image to the use the clone. Then I can do simple PR and review the issues. I will do the installation several times to learn (but not clone). I'm not sure that it is needed but I have cd /Users/ducasse/Library/Preferences/pharo/7.0 StartupPreferencesLoader default executeAtomicItems: { StartupAction name: 'Git Settings' code: [ FileStream stdout cr; nextPutAll: 'Setting the ssh credentials'; cr. Iceberg enableMetacelloIntegration: true. IceCredentialsProvider useCustomSsh: true. IceCredentialsProvider sshCredentials username: 'git'; publicKey: '/Users/ducasse/.ssh/id_rsa.pub'; privateKey: '/Users/ducasse/.ssh/id_rsa'. IceCredentialsProvider plaintextCredentials: (IcePlaintextCredentials new username: 'Ducasse'; password: 'xxxx' ; yourself ). FileStream stdout cr; nextPutAll: 'Finished'; cr ]. }. On Fri, Aug 11, 2017 at 9:46 AM, Guillermo Polito <[hidden email]> wrote:
|
Hi, I am now able to use iceberg on windows, thanks for the help.- load the slice from a fogbugz number and was able to review the change up to pharo 6 I just - load the latest image in pharolauncher (or from the command line). - opened the inbox repository. - load and review change/fix - throw away this change (close image without save) - reopen that image to move on with the next item to review. And do I this only in the command line or do I manage my fork (and keep it up to date) from within pharo with iceberg ? I would like do this steps, (as I was used to it from the prior contribution process, by loading code from the inbox) - Just look at the changesAnd the same for creating a fix / pull request. Do I need to be up to date with my own fork, or only the local copy of the pharo repository ? Again, for pharo 6 I would just load a latest image, make my changes / code fixes and create a slice. Save to the inbox -> done. And looking at iceberg, I have really no clue how to upload a fix. 2017-08-11 19:30 GMT+02:00 Stephane Ducasse <[hidden email]>:
|
Le 31/08/2017 à 00:06, Nicolai Hess a écrit :
> Hi, > > I am now able to use iceberg on windows, thanks for the help. > > But I am still a bit unsure about how the review and contribution > workflow should work. > > up to pharo 6 I just load a latest image, > - load the slice from a fogbugz number and was able to review the change > - or create a slice and upload it to the inbox > > in pharo 7 > - what is the equivalent to "getting the latest image" (and being able > to load and review a fix), > up to pharo 6 I just > - load the latest image in pharolauncher (or from the command line). > - opened the inbox repository. > - load and review change/fix > - throw away this change (close image without save) > - reopen that image to move on with the next item to review. > I'll not be of a great help here since I only reviewed PR via the github interface for now but I know that Guille wrote this guide: https://github.com/guillep/PharoIntegrationProcess/wiki/Pharo-Development-Process There is a review process discription. > But now, do I have to update my local branch for every new pull > request ? And how do I do this ? In other git project I would, I would > fetch upstream, checkout master, merge with upstream/master, push > the master to my fork origin > How should this be done with my pharo 7 fork ? (And do we only work > on the development brach instead of the master)? > > And do I this only in the command line or do I manage my fork (and > keep it up to date) from within pharo with iceberg ? > How do I actually access the pull requests from within pharo ? Maybe > I am stupid, but I just can not find it. > I would like do this steps, (as I was used to it from the prior > contribution process, by loading code from the inbox) > - Just look at the changes > - apply the changes > - throw away this changes, and move one with the next fix review > > And the same for creating a fix / pull request. Do I need to be up to > date with my own fork, or only the local copy of the pharo repository ? > Again, for pharo 6 I would just load a latest image, make my changes / > code fixes and create a slice. Save to the inbox -> done. > And looking at iceberg, I have really no clue how to upload a fix. > origin repository but it's recommended to sync once in a while to not create conflics if changes happen in the same part of the system that you'll change. The process is described here: https://github.com/guillep/PharoIntegrationProcess/wiki/Keep-your-repo-in-sync In general this will do the trick: $ git checkout development (if not already on development) $ git pull [PHARO_ORIGIN] development $ git push [FORK_ORIGIN] development > I see that other people are using the new process, and I feel a bit lost > and closed out of the pharo 7 development process, as I am at the moment > unable to understand how this work. > Are there any other resources I missed ? > > I use the new process but I already had some knowledge of git. I used it to manage team work at the university and I used it with smalltalk's projects and file tree. Also I asked a looot of questions to esteban/pavel/guille. The process need to be improved again and I still often have troubles. (I got one vm crash and two iceberg crash today while contributing for example). I try to report the maximum of my reproducible problem here: https://github.com/pharo-vcs/iceberg/issues If you see trouble with Iceberg it could be cool to give info to help to ease the contribution process. For your last question, the resources I use are mostly the wiki of Guille: https://github.com/guillep/PharoIntegrationProcess/wiki My knowledge of git and the help of people like esteban/guille/pavel/marcus… I hope some of those resources can help you. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France signature.asc (836 bytes) Download Attachment |
2017-08-31 0:28 GMT+02:00 Cyril Ferlicot D. <[hidden email]>: Le 31/08/2017 à 00:06, Nicolai Hess a écrit : Thank you Cyril. Do we have a list of links to this and other usefull articles or how did you know about this article? |
On Thu, Aug 31, 2017 at 12:42 AM, Nicolai Hess <[hidden email]> wrote:
> > Thank you Cyril. > > Do we have a list of links to this and other usefull articles or how did you > know about this article? > > Most of those articles comes from the same wiki that Guille gave in the first message of this thread. I just explored it :) But for the review process one I had to ask to Guille because I did not though I could have found it under "Pharo Development Process". And for some other articles I search on google. (To get the stHub to git migration script of Peter for example) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France |
In reply to this post by Nicolai Hess-3-2
> On 31 Aug 2017, at 00:06, Nicolai Hess <[hidden email]> wrote: > > Hi, > > I am now able to use iceberg on windows, thanks for the help. > > But I am still a bit unsure about how the review and contribution workflow should work. > > up to pharo 6 I just load a latest image, > - load the slice from a fogbugz number and was able to review the change > - or create a slice and upload it to the inbox > > in pharo 7 > - what is the equivalent to "getting the latest image" (and being able to load and review a fix), > up to pharo 6 I just > - load the latest image in pharolauncher (or from the command line). > - opened the inbox repository. > - load and review change/fix > - throw away this change (close image without save) > - reopen that image to move on with the next item to review. > > But now, do I have to update my local branch for every new pull request ? And how do I do this ? In other git project I would, I would > fetch upstream, checkout master, merge with upstream/master, push the master to my fork origin > How should this be done with my pharo 7 fork ? (And do we only work on the development brach instead of the master)? > > And do I this only in the command line or do I manage my fork (and keep it up to date) from within pharo with iceberg ? > How do I actually access the pull requests from within pharo ? Maybe I am stupid, but I just can not find it. > I would like do this steps, (as I was used to it from the prior contribution process, by loading code from the inbox) > - Just look at the changes > - apply the changes > - throw away this changes, and move one with the next fix review > > And the same for creating a fix / pull request. Do I need to be up to date with my own fork, or only the local copy of the pharo repository ? > Again, for pharo 6 I would just load a latest image, make my changes / code fixes and create a slice. Save to the inbox -> done. > And looking at iceberg, I have really no clue how to upload a fix. > > I see that other people are using the new process, and I feel a bit lost and closed out of the pharo 7 development process, as I am at the moment unable to understand how this work. > Are there any other resources I missed ? > Hi, Cyril send already the links to the description… I have to admit that i am myself in the “this is very very slow and cumbersome” phase of things… we need to streamline the process (I manage to do last week one pull request and this week one, this is not the speed that i want ;-) Marcus |
Free forum by Nabble | Edit this page |