January 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #17: SUCCESS

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #17 was: SUCCESS. Could not extract further issue information from commit message: Merge branch 'Pharo7.0' into Pharo8.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 22, 2019

[Pharo 7.0] Build #136: SUCCESS

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #136 was: SUCCESS. Could not extract further issue information from commit message: fix upload of release versions Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 22, 2019

[Pharo 7.0] Build #134: 22903-backport-to-P70fixes-on-bootstrap-scripts

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #134 was: FAILURE. The Pull Request #2285 was integrated: "22903-backport-to-P70fixes-on-bootstrap-scripts" Pull request url: https://github.com/pharo-project/pharo/pull/2285 Issue Url: https://pharo.fogbugz.com/f/cases/22903 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 22, 2019

Re: [Pharo-dev] contribution workflow

by Guillermo Polito

Hi Ben, I'll just expand a bit on what Pavel said. On Mon, Jan 21, 2019 at 4:59 PM Ben Coman <btc(a)openinworld.com> wrote: > I'm not sure how closely my contribution workflow matches the standard > advertised, so just wanted to share it for feedback. I may remember > wrongly, but my understanding of the advertised process was forking the > "pharo-project/pharo" repo, then cloning from my fork. However I found it > awkward to keep the "master" branch of my fork synchronised with upstream. > It's important to understand that you don't need to keep any branch in your fork synchronized ^^. Pull requests bind two branches, not two repositories. Your repository may have 30 branches, all outdated, and the only one that needs to be "up to date" is the one participating in a pull request. Even, I'd say it's not really required to have the branch of the PR up to date either, as git will just make a merge with it, calculating correctly the point of divergence between the two branches. However, making a branch that started too far away in the history (too old) will just increase the possibility of a merge conflict. Actually, the easiest is that you start working on a branch whose tip points to the same commit the image was created from. This is to make sure that: - you will have correct diffs - your PR does not introduce commits that you did not intend to And that's what Iceberg repair actions will guide you to. > What I ended up finding easiest is *always* cloning "pharo-project/pharo" > then adding my "bencoman/pharo" repo as a remote. Iceberg then makes it > simple to push just my working branches to my fork from where I can issue a > PR. I never need to trouble synchronising the master branch in my fork. > > How does that compare to your contribution workflow? > What I do: - I download a new image, that was built from commit xxx (the image and iceberg know that, so you don't have to care about it) - then I clone pharo from my fork, or I make the existing pharo repo point to an existing clone - (this is automatically done for you) iceberg github integration will make a request to github asking if the repository is a fork or not, and in the case IT IS it will configure the remotes for you - iceberg will most surely tell me "Fetch required". This means that the commit of my image is not in the cloned repository. I do a fetch. - Then I create a branch from my image commit >From that point on, everything is up and running. You can just work, commit, push to your fork, make a PR. > > cheers -ben > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Jan. 22, 2019

Re: [Pharo-dev] contribution workflow

by Pavel Krivanek

You may simply clone your fork because the synchronization between it and the upstream repository is done automatically if you are contributing using Iceberg. When you are creating a branch from your image commit, Iceberg fetches the main Pharo repository to obtain information about the required commit and your fork is updated as soon as you commit the fix. The same thing is true for the other projects too as soon as you clone the repository using the option "Clone From github.com" because this operation uses the GitHub API to obtain information about the repository from which your repository was forked. It is not the case for the option "Clone remote repository". To contribute to Pharo, follow this documentation: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo Cheers, -- Pavel po 21. 1. 2019 v 16:59 odesÃlatel Ben Coman <btc(a)openinworld.com> napsal: > I'm not sure how closely my contribution workflow matches the standard > advertised, so just wanted to share it for feedback. I may remember > wrongly, but my understanding of the advertised process was forking the > "pharo-project/pharo" repo, then cloning from my fork. However I found it > awkward to keep the "master" branch of my fork synchronised with upstream. > > What I ended up finding easiest is *always* cloning "pharo-project/pharo" > then adding my "bencoman/pharo" repo as a remote. Iceberg then makes it > simple to push just my working branches to my fork from where I can issue a > PR. I never need to trouble synchronising the master branch in my fork. > > How does that compare to your contribution workflow? > > cheers -ben >

Jan. 21, 2019

contribution workflow

by Ben Coman

I'm not sure how closely my contribution workflow matches the standard advertised, so just wanted to share it for feedback. I may remember wrongly, but my understanding of the advertised process was forking the "pharo-project/pharo" repo, then cloning from my fork. However I found it awkward to keep the "master" branch of my fork synchronised with upstream. What I ended up finding easiest is *always* cloning "pharo-project/pharo" then adding my "bencoman/pharo" repo as a remote. Iceberg then makes it simple to push just my working branches to my fork from where I can issue a PR. I never need to trouble synchronising the master branch in my fork. How does that compare to your contribution workflow? cheers -ben

Jan. 21, 2019

[Pharo 8.0] Build #16: FAILURE

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #16 was: FAILURE. Could not extract further issue information from commit message: Merge branch 'Pharo7.0' into Pharo8.0 # Conflicts: # bootstrap/scripts/envversion.sh # bootstrap/scripts/transform_32_into_64.sh Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

[Pharo 7.0] Build #133: 22903-backport-to-P70fixes-on-bootstrap-scripts

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #133 was: FAILURE. The Pull Request #2285 was integrated: "22903-backport-to-P70fixes-on-bootstrap-scripts" Pull request url: https://github.com/pharo-project/pharo/pull/2285 Issue Url: https://pharo.fogbugz.com/f/cases/22903 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

[Pharo 8.0] Build #15: Added tests about Context>>home and Context>>activeHome

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #15 was: FAILURE. The Pull Request #2278 was integrated: "Added tests about Context>>home and Context>>activeHome" Pull request url: https://github.com/pharo-project/pharo/pull/2278 Issue Url: https://pharo.fogbugz.com/f/cases/2277 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019

[Pharo 7.0] Build #132: 22887-TonelWritercreateDefaultOrganizationFrom-can-return-string

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #132 was: FAILURE. The Pull Request #2267 was integrated: "22887-TonelWritercreateDefaultOrganizationFrom-can-return-string" Pull request url: https://github.com/pharo-project/pharo/pull/2267 Issue Url: https://pharo.fogbugz.com/f/cases/22887 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2019