How to manage GitFileTree and being integrated in-image (QualityAssistant example?)
Hi guys, Let's say there is a project which is being build with metadata-less GitFileTree. There is a BaselineOf and a ConfigurationOf which work correctly. And ConfigurationOf can perfectly have fixed "versions" that could be, at some point, integrated in Pharo. Let's say I release version 1.0 which is INTEGRATED inside Pharo. When Pharo image is build, it uses ConfigurationOfMyApp to load the code and so there will be NO history of versions (cypress.1). Now, as Pharo goes on, there may be changes to that project as part of refactors or whatever that happens in-image. So in one months from now, Pharo may have a "newer" code than the originally released 1.0. Let's say that for the package MyAppPackage were only 3 commits in those 2 months. At the same time, I have continue working with my project, and I am ready to publish 1.1. Question is.... how do I bring Pharo changes to my own place? 1) Fetching (from Pharo repo) and pushing to my GitFileTree only the versions during those 2 months? I doubt this will work as crappy Monticello numbers could have collisions, right? 2) Doing a poor man diff and cherry picking changes from Pharo repo and manually apply them to my own repo? In this case, the "3 commits" of those 2 months will be lost as from git history version. Is there a project doing this?? I know QualityAssistant is close, but he does not use metadata-less GitFileTree I think...so I am not sure. Thoughts? Thanks! -- Mariano http://marianopeck.wordpress.com
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. (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. Thierry * There is a bit of code to write, of course, but most of it is reusing what already exists inside Skip github and GitFileTree. 2016-01-22 14:33 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi guys,
Let's say there is a project which is being build with metadata-less GitFileTree. There is a BaselineOf and a ConfigurationOf which work correctly. And ConfigurationOf can perfectly have fixed "versions" that could be, at some point, integrated in Pharo.
Let's say I release version 1.0 which is INTEGRATED inside Pharo. When Pharo image is build, it uses ConfigurationOfMyApp to load the code and so there will be NO history of versions (cypress.1).
Now, as Pharo goes on, there may be changes to that project as part of refactors or whatever that happens in-image. So in one months from now, Pharo may have a "newer" code than the originally released 1.0. Let's say that for the package MyAppPackage were only 3 commits in those 2 months.
At the same time, I have continue working with my project, and I am ready to publish 1.1.
Question is.... how do I bring Pharo changes to my own place?
1) Fetching (from Pharo repo) and pushing to my GitFileTree only the versions during those 2 months? I doubt this will work as crappy Monticello numbers could have collisions, right?
2) Doing a poor man diff and cherry picking changes from Pharo repo and manually apply them to my own repo? In this case, the "3 commits" of those 2 months will be lost as from git history version.
Is there a project doing this?? I know QualityAssistant is close, but he does not use metadata-less GitFileTree I think...so I am not sure.
Thoughts?
Thanks!
-- Mariano http://marianopeck.wordpress.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 ... 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? 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) ?
(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.
Thierry
* There is a bit of code to write, of course, but most of it is reusing what already exists inside Skip github and GitFileTree.
2016-01-22 14:33 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi guys,
Let's say there is a project which is being build with metadata-less GitFileTree. There is a BaselineOf and a ConfigurationOf which work correctly. And ConfigurationOf can perfectly have fixed "versions" that could be, at some point, integrated in Pharo.
Let's say I release version 1.0 which is INTEGRATED inside Pharo. When Pharo image is build, it uses ConfigurationOfMyApp to load the code and so there will be NO history of versions (cypress.1).
Now, as Pharo goes on, there may be changes to that project as part of refactors or whatever that happens in-image. So in one months from now, Pharo may have a "newer" code than the originally released 1.0. Let's say that for the package MyAppPackage were only 3 commits in those 2 months.
At the same time, I have continue working with my project, and I am ready to publish 1.1.
Question is.... how do I bring Pharo changes to my own place?
1) Fetching (from Pharo repo) and pushing to my GitFileTree only the versions during those 2 months? I doubt this will work as crappy Monticello numbers could have collisions, right?
2) Doing a poor man diff and cherry picking changes from Pharo repo and manually apply them to my own repo? In this case, the "3 commits" of those 2 months will be lost as from git history version.
Is there a project doing this?? I know QualityAssistant is close, but he does not use metadata-less GitFileTree I think...so I am not sure.
Thoughts?
Thanks!
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
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.
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
On Fri, Jan 22, 2016 at 1:39 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
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.
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
Le 23/01/2016 19:00, Mariano Martinez Peck a écrit :
On Fri, Jan 22, 2016 at 1:39 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>:
On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto: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.
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.
What is nice in there is that you have a clear way to open upstream to contributions (pull requests and issues) and manage those. In practice, I'd guess contributors will do the fork only once. But they will have to learn to keep it up to date with the upstream project :)
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.
Yes. Especially since in such a change, you want to merge in two places: a successor to the tag (a v1.1.3 if it was v1.1.2) to release a new stable with the change for integration in the Pharo image, and a merge into your development branch.
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.
Thierry
participants (2)
-
Mariano Martinez Peck -
Thierry Goubier