2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck <[email protected]>:
> > > On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier < > [email protected]> 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. > In either case, just to confirm, we do NOT do fetch/push because of the > versions problem right? > I mean...it will be either me or another guy (the guy that created the > issue), but one of us will finally end up putting the "changes" (not a MC > version) in the upstream whatever ways are taking for that (via PR or > whatever) ? > Yes, but the push will be a MC version anyway? I don't understand; using git means that you can just save and push versions, and git will determine what the diff is... > (Was I clear with that description? Feel free to ask or correct me :)) >> >> Now, about the package versions. There is an issue with metadata-less >> mode and a few quirks about the way Metacello check versions to upgrade >> packages, and the issue is open. Two ways forward are possible: David >> Allouche pointed one by saying ordering between versions (without checking >> the numbers) can be resolved by checking if one is an ancestor of the >> other... and the other is that, with Skip work on the github api, it >> becomes possible(*) to retrieve the version info from github without git >> and avoid those -Cypress.1. >> >> > OK that would very cool. > Yes, I think so too. Thierry
