On Fri, Jan 22, 2016 at 1:39 PM, Thierry Goubier <[email protected]> wrote:
> > > 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. > Indeed. I have to admit that at the beginning I also thought it was quit a pain. But now that I have done that many times, I can confirm it's quite really easy. > > >> 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. > > That's a very cool path! The idea of making a branch from the last tag version is great. Then you are at the normal branch/merge behavior. > 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. > > Fully agree. Mariano http://marianopeck.wordpress.com
