2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:

On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Mariano,

this is a common question for external projects integrated inside the Pharo image. And we have an issue with version numbers, but let's try to keep that separate.

Fixes to the code of external projects integrated inside Pharo should be done upstream (on the external project itself), not in the Pharo image. This is what is currently happening with the GT tools, NeoJSON, Zinc, and probably a few more. So, as a maintainer of such a projects in github, say, you can ask people to create issues on your project, pull requests and the like, and this is the only way bugs found in Pharo in your release project should be corrected. Then, everytime a new version of the Pharo image is built, a version of your project is integrated; and you can add an issue to update your project to a newer version inside Pharo.

Well, that covers A PART of the problem. If someone finds a bug or whatever in MY project, then your workflow sounds perfect.

Now...consider internal refactors of Pharo that affects multiple projects. For example few months ago, someone changes all senders of #instVarNames to #instanceVariabls (or something like that...I don't remember the exact change but something like that). As part of those senders, there was Fuel. So when that SLICE was integrated (with multiple packages as dependencies of the SLICE), Fuel package was one of them.��

So what should be the path in this case:

1) Ask the poor guy that make the slice to also do the fork, git clone, install gitfiletree, commit, push and make PR ��...��

Hum, takes about:

- 1 click or two on github for the fork

- 1 click on the configuration manager for gitfiletree

- 4 lines of metacello for remote clone + repository

- 3 clicks and a bit of text for the commit in the fork

- two clicks for the push to github

- 2 or 3 clicks for the pull request

Soon (or even already now?), Skip Github code would allow that without git/gitfiletree. But in github world, you would need a fork anyway.

��

2) Myself (as the developer of the tool) get notified when my package gets changed and then, I take care of doing a diff and manaully "port" the fix to my upstream project?��

Probably this one. Technically, it is easy to: get the latest image; get the gitfiletree repository; create a branch at the previous stable version of the project; save the changed packages into that branch; then decide (git merge?) those changes into either a new stable version or on a development branch. Git will take care of the difference between your new stuff and the stuff changed in Pharo, and merge properly unless both sides have changed the same method / line in a method.

I don't expect this sort of changes to occur very often. As you say, this is a particular use case, with a large number of packages changed, so I would consider that a rare occurrence for which I don't have to specially optimize the process, just to have it possible. Smaller fixes should be done the 1) way.