Cannot use Zinc in Pharo7 anymore
I asked this before because I donât get it. External packages like Zinc seem to be modified when integrated into pharo. Looking at the changes between to newest Zinc from Svenâs repository and the one in pharo there are a few differences. As an example there is ZnCharacterReadWriteStream>>#tab writeStream tab Where is this method added? Are the changes pushed back to Sven? In my project I use Zinc-REST. So I need to add the repository for Zinc and load the REST group. When this is loaded it pulls in the other Zinc packages which removes the methods like the one above and my image gets stuck because Epicea relies on that method and I get a debugger. So at the moment I can only create a new image when I disable Epicea. Why is it done that way? Best would be to use the version from Sven and make changes there. If that is not possible it would be good to use an extra package that does extension methods to Zinc. But this way is asking for trouble IMHO. Norbert
On 1 Nov 2018, at 14:38, Norbert Hartl <norbert@hartl.name> wrote:
I asked this before because I donât get it. External packages like Zinc seem to be modified when integrated into pharo.
When a new version of Zinc is integrated, it is done as-is. The problem is that people keep on changing things afterwards.
Looking at the changes between to newest Zinc from Svenâs repository and the one in pharo there are a few differences. As an example there is
ZnCharacterReadWriteStream>>#tab writeStream tab
Where is this method added?
I don't know, this is the first time I see that particular one.
Are the changes pushed back to Sven?
I do this all by hand myself, afterwards. It is sometimes quite a bit of annoying work.
In my project I use Zinc-REST. So I need to add the repository for Zinc and load the REST group. When this is loaded it pulls in the other Zinc packages which removes the methods like the one above and my image gets stuck because Epicea relies on that method and I get a debugger. So at the moment I can only create a new image when I disable Epicea.
Yes, this is really annoying.
Why is it done that way? Best would be to use the version from Sven and make changes there. If that is not possible it would be good to use an extra package that does extension methods to Zinc. But this way is asking for trouble IMHO.
Norbert
Yes, I would also prefer things to go to Zn first. But then it takes longer for people to see their changes in the base image. Now to be fair, the new file/stream changes did require a shorter feedback loop in pharo itself. I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it. Sven
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert, I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more. Could you please test ? Thx, Sven
Hi,
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
I think I have to. Usually it is not possible to load something from bleedingEdge and Zinc is used all over the place. But as it is you I change it ;) Norbert
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch. Norbert
Hi Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo. I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here. Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive). I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us. Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee??? Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
On 2 Nov 2018, at 12:01, Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions.
Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
Am 02.11.2018 um 12:23 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 2 Nov 2018, at 12:01, Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers.
It seems Iâm not very clear when writing mails. I understand why this happens and I understand it needs to be that way because of less annoyance and improved speed. I donât understand how it is done explicitly. As we have a process that builds the image where are those changes applied? Is there a copy of the original package that gets tweaked?
I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos.
Yes, Iâm getting used to git although I donât like it. One reason I took several days time to help migrate projects from smalltalkhub to github is exactly this. In order to make myself independent I fork the projects I consider unstable and use the fork in our product. This way I have control when there is something updated. This could also be a good way for pharo. If there is a github project where every external project is forked to and used in pharo. This way you can control upstream and you can add tweaks that are needed for a release. Iâm intrigued which approaches people do for what reasons.
I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions.
Agreed. Norbert
Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
NorbertHartl wrote
In order to make myself independent I fork the projects I consider unstable and use the fork in our product. This way I have control when there is something updated. This could also be a good way for pharo.
I was thinking the same. This is also what I do. My goal is *never* to depend on external projects, only my forks. With GH this is trivial. With mcz repos it was much harder IMHO. And it seems to address Steph's valid concern because you just commit to your fork and keep moving ahead - no waiting, just create a PR and it's up to the maintainer to accept or not. BTW This concept of forking and insulating oneself from unstable external projects IMHO is *the* killer feature of GH for Smalltalk/Pharo workflows. How many hours I wasted trying to contact "maintainers" of abandonware mcz repos to integrate a fix! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
So the killer feature is not the possibility to report issues, propose and link corrections, enhancements and new features to be merged back, have them automatically tested on continuous integration bots, comment code online and have discussions about implementation correctness or style... If killer feature is not the social part, then we don't really need github. Git, MC, or any other distributed VCS already handle the trivial ability to fork. Forking is very important for handling concurrent timelines. But a good fork is a fork that is merged back, because it preserves retro contributions. If divergence of interest is too high, then yes, the ability to definitely fork is important, but it should be last resort decision. IMO, time spent to convince that a change must be merged back is not lost time. Unless the change is not that good. A fork is a super easy and convenient way to handle the case in short term. But long term divergences soon become unsustainable drag. So please, be social and cooperative and favor win-win strategies :) Le 3 nov. 2018 03:25, "Sean P. DeNigris" <sean@clipperadams.com> a écrit : NorbertHartl wrote
In order to make myself independent I fork the projects I consider unstable and use the fork in our product. This way I have control when there is something updated. This could also be a good way for pharo.
I was thinking the same. This is also what I do. My goal is *never* to depend on external projects, only my forks. With GH this is trivial. With mcz repos it was much harder IMHO. And it seems to address Steph's valid concern because you just commit to your fork and keep moving ahead - no waiting, just create a PR and it's up to the maintainer to accept or not. BTW This concept of forking and insulating oneself from unstable external projects IMHO is *the* killer feature of GH for Smalltalk/Pharo workflows. How many hours I wasted trying to contact "maintainers" of abandonware mcz repos to integrate a fix! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Nicolas Cellier wrote
If killer feature is not the social part, then we don't really need github. Git, MC, or any other distributed VCS already handle the trivial ability to fork.
Okay, fine ha ha, the social part is *the* killer advantage. Perhaps I should've inserted "committing" before "workflow". As to the triviality, IMHO it doesn't get much simpler than clicking "Fork" and then "Create PR", and I don't know of anything nearly that simple in the mcz world. Maybe per-project inboxes might have helped a bit, but always more to do than resources. Nicolas Cellier wrote
IMO, time spent to convince that a change must be merged back is not lost time.
Sure, but the key now is that you can do all that convincing *after* you continue with your own work, instead of being stalled. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Sven I agree with you. Ideally we would like to have much better tooling and process. Now the last time we discussed with Guille and Pablo about it: they estimated that this is over one year of work. And right now we do not have this engineering time to invest on this because other fronts need to be addressed. Still this is really slowing us. This is simple: I stopped thinking to improve something that touches external packages. So I will not work on the trivial changes that would improve Calypso/Iceberg. Why? Because this is tedious, boring, not rewarding. So yes we can do easily with iceberg simple fix on not external packages but as soon as - you need to load latest dev version (which can be a different one than the current one) - update your repo - fix - do a PR - .... wait for its integration So at the end we as a community can ask ourselves what is the reward model for such shitty work? And also what are we ready to give so that Pharo maintainers do such boring job. Right now without really doing it consciously I see myself doing either stupid fix or working on side projects and this is not a good long term approach because the core of Pharo needs a lot of work. Stef On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 2 Nov 2018, at 12:01, Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers.
I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos.
I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions.
Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
Just to share my pain with you. Try to change something in the API of Commander? I think that it will be nearly impossible. Because Iceberg/Calypso depend on Commander and they are all managed in different repositories. So it means - fork each - probably introduce automatic deprecation - do a PR for each of the subprojects (it means identify for each one if we should work on dev or master and being able to checkout the correct version which is not always possible) - then waits.....that may be each of the PR got integrated - now you lost total focus - if one day you recover what you were doing then and only then you may finish your change. Good luck. So to me the message is clear: stay away. And this is what I'm doing. We are damaging our agility on the altar of a pseudo modularity. So this is why I will focus on my tiny, uninteresting side projects. Stef On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Sven
I agree with you. Ideally we would like to have much better tooling and process. Now the last time we discussed with Guille and Pablo about it: they estimated that this is over one year of work. And right now we do not have this engineering time to invest on this because other fronts need to be addressed. Still this is really slowing us. This is simple: I stopped thinking to improve something that touches external packages. So I will not work on the trivial changes that would improve Calypso/Iceberg. Why? Because this is tedious, boring, not rewarding. So yes we can do easily with iceberg simple fix on not external packages but as soon as - you need to load latest dev version (which can be a different one than the current one) - update your repo - fix - do a PR - .... wait for its integration
So at the end we as a community can ask ourselves what is the reward model for such shitty work? And also what are we ready to give so that Pharo maintainers do such boring job.
Right now without really doing it consciously I see myself doing either stupid fix or working on side projects and this is not a good long term approach because the core of Pharo needs a lot of work.
Stef On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 2 Nov 2018, at 12:01, Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers.
I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos.
I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions.
Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
Yes this is an emerging problem - I had a similar thing trying to add better navigation support to pharo7 as my change touched core and Calypso, so you had to get something into core and then loop back to get it approved in Calypso (a few weeks later). In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together? We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute. Tim Sent from my iPhone
On 4 Nov 2018, at 22:35, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Just to share my pain with you. Try to change something in the API of Commander? I think that it will be nearly impossible. Because Iceberg/Calypso depend on Commander and they are all managed in different repositories. So it means - fork each - probably introduce automatic deprecation - do a PR for each of the subprojects (it means identify for each one if we should work on dev or master and being able to checkout the correct version which is not always possible) - then waits.....that may be each of the PR got integrated - now you lost total focus - if one day you recover what you were doing then and only then you may finish your change.
Good luck.
So to me the message is clear: stay away. And this is what I'm doing. We are damaging our agility on the altar of a pseudo modularity.
So this is why I will focus on my tiny, uninteresting side projects. Stef
On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Sven
I agree with you. Ideally we would like to have much better tooling and process. Now the last time we discussed with Guille and Pablo about it: they estimated that this is over one year of work. And right now we do not have this engineering time to invest on this because other fronts need to be addressed. Still this is really slowing us. This is simple: I stopped thinking to improve something that touches external packages. So I will not work on the trivial changes that would improve Calypso/Iceberg. Why? Because this is tedious, boring, not rewarding. So yes we can do easily with iceberg simple fix on not external packages but as soon as - you need to load latest dev version (which can be a different one than the current one) - update your repo - fix - do a PR - .... wait for its integration
So at the end we as a community can ask ourselves what is the reward model for such shitty work? And also what are we ready to give so that Pharo maintainers do such boring job.
Right now without really doing it consciously I see myself doing either stupid fix or working on side projects and this is not a good long term approach because the core of Pharo needs a lot of work.
Stef
On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 2 Nov 2018, at 12:01, Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers.
I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos.
I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions.
Norbert
Stef
On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter. With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well. Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints. With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo. With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable. So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate. Is this helpful? Stephan
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us. Stef On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos cheers -ben On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. Tim Sent from my iPhone
On 7 Nov 2018, at 05:48, Ben Coman <btc@openinworld.com> wrote:
I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos
cheers -ben
On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
It is not so easy. A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0. Now, imagine If iceberg would be integrated in pharo. 1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? Of course, we could maintain a branch. But then I'd argüe is more or less the same as having a separated project. Situation is not ideal (even if it is a lot better as before). But Iâm envisioning this solution: add multiple source directories capability. Then we can have: src/kernel src/system src/spec src/iceberg src/calypso etc. This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy). Esteban Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too.
On 7 Nov 2018, at 07:02, Tim Mackinnon <tim@testit.works> wrote:
Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well).
When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes.
I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better).
For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis.
I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help.
Tim
Sent from my iPhone
On 7 Nov 2018, at 05:48, Ben Coman <btc@openinworld.com> wrote:
I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos
cheers -ben
On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
On Wed, 7 Nov 2018 at 17:16, Esteban Lorenzano <estebanlm@gmail.com> wrote:
It is not so easy.
A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0.
Now, imagine If iceberg would be integrated in pharo.
1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? Of course, we could maintain a branch. But then I'd argüe is more or less the same as having a separated project.
Situation is not ideal (even if it is a lot better as before). But Iâm envisioning this solution: add multiple source directories capability.
Then we can have:
src/kernel src/system src/spec src/iceberg src/calypso etc.
This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy).
Why not a submodule approach? I do vaguely remember you having some pain with it integrating the opensmalltalk-vm repo under the pharo-vm repo before Pharo started more directly using the opensmallk-vm CI products. I thought I might have something useful to contribute to discussion by finding the good article [1] I remembered that compared subtree and submodule, the summary of which is... * Is the external repository something you own yourself and are likely to push code back to? Then use a submodule. This gives you the quickest and easiest way for you to push your changes back. * Is the external repository third party code that you are unlikely to push anything back to? Then use a subtree. This gives the advantage of not having to give people permissions to an extra repo when you are giving them access to the code base, and also reduces the chance that someone will forget to run a git submodule update. [But this could be automated in Pharo] But then I came across [2] which says... * Submodules [...] work well when you want to include a third-party library in your project that only occasionally needs to be updated. so I don't know. [1] https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/ [2] http://www.mos6581.org/git_subtree_alternative I think main issues to consider between the two options are: A. the effect on history between Pharo repo and dependent repos, of commits to either repo B. how branching is handled between Pharo repo and dependent repos and I don't know really have my head around that, so for now I'll shut it. :) anyway, my understanding was that subtree was implemented in shell scripts and not libgit so does that make it more difficult? https://stackoverflow.com/a/25474895 cheers -ben
Esteban
Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too.
On 7 Nov 2018, at 07:02, Tim Mackinnon <tim@testit.works> wrote:
Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well).
When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes.
I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better).
For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis.
I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help.
Tim
Sent from my iPhone
On 7 Nov 2018, at 05:48, Ben Coman <btc@openinworld.com> wrote:
I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos
cheers -ben
On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
On 7 Nov 2018, at 14:19, Ben Coman <btc@openinworld.com> wrote:
On Wed, 7 Nov 2018 at 17:16, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
It is not so easy.
A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0.
Now, imagine If iceberg would be integrated in pharo.
1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? Of course, we could maintain a branch. But then I'd argüe is more or less the same as having a separated project.
Situation is not ideal (even if it is a lot better as before). But Iâm envisioning this solution: add multiple source directories capability.
Then we can have:
src/kernel src/system src/spec src/iceberg src/calypso etc.
This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy).
Why not a submodule approach?
Donât know, donât care for the moment :) We need to add multiple subdirectories capability. Then we will be able to chose whatever we want: submodules, subtrees, nothing at all.
I do vaguely remember you having some pain with it integrating the opensmalltalk-vm repo under the pharo-vm repo before Pharo started more directly using the opensmallk-vm CI products.
That was my own stupidity, not subtree problems ;)
I thought I might have something useful to contribute to discussion by finding the good article [1] I remembered that compared subtree and submodule, the summary of which is...
* Is the external repository something you own yourself and are likely to push code back to? Then use a submodule. This gives you the quickest and easiest way for you to push your changes back.
* Is the external repository third party code that you are unlikely to push anything back to? Then use a subtree. This gives the advantage of not having to give people permissions to an extra repo when you are giving them access to the code base, and also reduces the chance that someone will forget to run a git submodule update. [But this could be automated in Pharo]
But then I came across [2] which says... * Submodules [...] work well when you want to include a third-party library in your project that only occasionally needs to be updated.
so I don't know. [1] https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/ <https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/> [2] http://www.mos6581.org/git_subtree_alternative <http://www.mos6581.org/git_subtree_alternative>
I think main issues to consider between the two options are: A. the effect on history between Pharo repo and dependent repos, of commits to either repo B. how branching is handled between Pharo repo and dependent repos and I don't know really have my head around that, so for now I'll shut it. :)
anyway, my understanding was that subtree was implemented in shell scripts and not libgit so does that make it more difficult? https://stackoverflow.com/a/25474895 <https://stackoverflow.com/a/25474895>
Everything in git is implemented as shell scripts (thatâs why libgit2 exists, in fact). In any case, we will not handle the subtree (or submodule) pushing/pulling from iceberg. Doing a proper tooling on subtree will be complicated and time-effort consuming and sadly we do not have time to prioritise that now, then it will be an external task, at least for the moment. Esteban
cheers -ben
Esteban
Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too.
On 7 Nov 2018, at 07:02, Tim Mackinnon <tim@testit.works> wrote:
Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well).
When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes.
I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better).
For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis.
I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help.
Tim
Sent from my iPhone
On 7 Nov 2018, at 05:48, Ben Coman <btc@openinworld.com> wrote:
I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos
cheers -ben
On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
It is not so easy.
A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0.
This is because you want to see it like that. Now issuing a new version of iceberg would just be integrated a branch into Pharo. So I do not see why you could not commit to a branch and work there for Iceberg. Sorry but I do not buy your argument. Why you want to have all the plugin of the VM at the same place and not the core Pharo tool? The message is clear to me: I will not work on Pharo because I cannot. You will show me how you do that trivially stupid bug fix without several PR AND synchronisation point!!!!!! Because if you do not see that the synchronisation point between a PR in project and a PR in Pharo will kill us. What can I say. Nothing I will shut up but do not ask my support for anything in the future. Sorry to be aggressive but this week I could have fixed several totally totally stupid glitches and I could not You will have to prove me that I'm wrong: https://pharo.fogbugz.com/f/cases/22626/Should-not-hardcode-CmdCommandAborte... And at the end, you will win and I will let you play with your process. And I will not work on Pharo.
Now, imagine If iceberg would be integrated in pharo.
1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? Of course, we could maintain a branch. But then I'd argüe is more or less the same as having a separated project.
Situation is not ideal (even if it is a lot better as before).
How better? We cannot fix simple crosscutting things in subparts of Pharo?
But Iâm envisioning this solution: add multiple source directories capability.
This does not resolve the synchronisation point. And I do not see how it helps other projects like Moose with multiple repo so we lose on two sides. 1 Too complex for Pharo core and 2 not helping projects build out of external projects. I think that we should work on more important things instead of building our own new problems. (cleaning, better tools, Cargo, headless, better VM, Modules?) Merging the Pharo core projects would solved the first (1) problem above. But you are right let us look smart and increase the entropy for the sake of it. It will be without me. I started and I will not read bug entries and PR anymore. If doing nothing is the way to get heard then I will do nothing because I'm hurt each time I want to do something and I have enough.
Then we can have:
src/kernel src/system src/spec src/iceberg src/calypso etc.
This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories.
I do not believe you. If that would be so easy why Pablo and Guille would tell me that this is around 8 months of work? Seriously.
For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy).
Esteban
Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too.
On 7 Nov 2018, at 07:02, Tim Mackinnon <tim@testit.works> wrote:
Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well).
When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes.
I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better).
For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis.
I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help.
Tim
Sent from my iPhone
On 7 Nov 2018, at 05:48, Ben Coman <btc@openinworld.com> wrote:
I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos
cheers -ben
On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
Isn't working with "core projects" in the Pharo repository an actual fork of each project? One thing is "Kernel" (which is seldom committed outside of the context of the Pharo repo) and another one is Calypso/Iceberg/Zinc, etc. What's the practical difference (in terms of code) between such a fork and depending on a particular commit/tag of the referenced project? ps: These are honest, maybe naive, questions, so please answer accordingly. Esteban A. Maringolo
Hi,
On 7 Nov 2018, at 22:26, Stephane Ducasse <stepharo.self@gmail.com> wrote:
It is not so easy.
A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0.
This is because you want to see it like that. Now issuing a new version of iceberg would just be integrated a branch into Pharo. So I do not see why you could not commit to a branch and work there for Iceberg. Sorry but I do not buy your argument. Why you want to have all the plugin of the VM at the same place and not the core Pharo tool?
I do want all sources in a single repository. Is just, I want it in a clean way, that will help us improve modularisation and task/team working. And in the case of VM, to be honest I would prefer to have the plugins separated, is just that is not possible as it is now because: - not all âpluginsâ are real plugins, in the sense I cannot take them out and expect the VM to work. Take âFilePluginâ as an example. This plugins are more like âmodulesâ that happens to use the same structure as real plugins. - plugins are all spread in the web. And they are split in two: Smalltalk part is in some place and platform files are all on osvm repository. *This* is annoying. A good organisation would be: - all VM sources with all required modules (mandatory plugins) together. - each real optional plugin in a separated repository along with their own makefiles, allowing the build of them without needing the full VM (but also allowing the build of the VM without needing to checkout the plugins). - and all of them organised under the same organisation (opensmalltalk) Also, having âall VM sources togetherâ does not means I want then all mixed. I would also like to have them correctly separated in something like: src vm smalltalk ... platform unix macOS windows modules filemodule smalltalk platforms unix macOS windows ... But this is a lot of work, and then we agreed in a solution that will work but is not the best. Now, I do believe we need to do steps to go there with the VM organisation and also with Pharo organisation. My proposal is to have all sources in a single repository, but organised in a way that enhance modularity and for the same price we can benefit of using subtrees (or submodules), but we do not need to do it, is your a choice. So, in my plans, I want to create this structure for Pharo sources: src kernel system graphics spec tools playground debugger calypso iceberg (this is just an example, whatever the tools are) ⦠And to achieve this, all we need is to add support to multiple directories to iceberg (which is something that is in our roadmap anyway). Cheers, Esteban
The message is clear to me: I will not work on Pharo because I cannot. You will show me how you do that trivially stupid bug fix without several PR AND synchronisation point!!!!!! Because if you do not see that the synchronisation point between a PR in project and a PR in Pharo will kill us. What can I say. Nothing I will shut up but do not ask my support for anything in the future. Sorry to be aggressive but this week I could have fixed several totally totally stupid glitches and I could not You will have to prove me that I'm wrong: https://pharo.fogbugz.com/f/cases/22626/Should-not-hardcode-CmdCommandAborte...
And at the end, you will win and I will let you play with your process. And I will not work on Pharo.
Now, imagine If iceberg would be integrated in pharo.
1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? Of course, we could maintain a branch. But then I'd argüe is more or less the same as having a separated project.
Situation is not ideal (even if it is a lot better as before).
How better? We cannot fix simple crosscutting things in subparts of Pharo?
But Iâm envisioning this solution: add multiple source directories capability.
This does not resolve the synchronisation point. And I do not see how it helps other projects like Moose with multiple repo so we lose on two sides. 1 Too complex for Pharo core and 2 not helping projects build out of external projects.
I think that we should work on more important things instead of building our own new problems. (cleaning, better tools, Cargo, headless, better VM, Modules?) Merging the Pharo core projects would solved the first (1) problem above.
But you are right let us look smart and increase the entropy for the sake of it. It will be without me. I started and I will not read bug entries and PR anymore. If doing nothing is the way to get heard then I will do nothing because I'm hurt each time I want to do something and I have enough.
Then we can have:
src/kernel src/system src/spec src/iceberg src/calypso etc.
This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories.
I do not believe you. If that would be so easy why Pablo and Guille would tell me that this is around 8 months of work? Seriously.
For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy).
Esteban
Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too.
On 7 Nov 2018, at 07:02, Tim Mackinnon <tim@testit.works> wrote:
Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well).
When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes.
I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better).
For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis.
I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help.
Tim
Sent from my iPhone
On 7 Nov 2018, at 05:48, Ben Coman <btc@openinworld.com> wrote:
I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos
cheers -ben
On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
Am 06.11.2018 um 19:54 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us.
It is not an easy decision. Either you bind everything closely to you and ease your workflow but have to do everything on your own. Or you welcome external projects not done by you and you enter modern dependency hell. Choose wisely or just try to solve the real problem. You neither have the time to develop everything by yourself nor have the patience to spend time on dependencies. Norbert
Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan@stack.nl> wrote:
Tim Mackinnon <tim@testit.works> wrote:
In retrospect, Iâm wondering if successful projects that have proved integration usefulness should be moved into the core repo? (Iceberg/Calypso?) or are we missing something to help easily track the journey of a multi faceted change (although this sounds overkill?). Or are there sprint days to try and knock these things through easily with everyone on board to do it together?
We are sort of damned if you do and damned if you donât. But certainly we want to endure that progress can be made without losing the will to contribute.
Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read
"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter.
With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well.
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints.
With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo.
With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable.
So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate.
Is this helpful?
Stephan
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes,
I'm curious what you meant by this. I'm not aware of Magma ever having been overwhelmed. Its design has made it easy to be one of the most-available and consumable pieces of software for every version of Squeak from 2007 to today. Did you mean the Pharo port? It doesn't really do any magic, I'd be surprised if it would be very difficult to port to Pharo, but I don't know. - Chris
Chris Muller <asqueaker@gmail.com> wrote:
Earlier, weâve seen projects like Magma being overwhelmed by the number of needed changes,
I'm curious what you meant by this. I'm not aware of Magma ever having been overwhelmed. Its design has made it easy to be one of the most-available and consumable pieces of software for every version of Squeak from 2007 to today. Did you mean the Pharo port? It doesn't really do any magic, I'd be surprised if it would be very difficult to port to Pharo, but I don't know.
Several people have been working on a Magma version for Pharo. At the time (Pharo 1.0-1.2) the Pharo CI infrastructure was not giving enough feedback to keep the port running. Once a year or so someone comes along who tries fixing the port, and that appears to be too difficult or time consuming for them. It needs pretty deep knowledge about internals. I agree that it would probably not be very difficult for a long time pharo/squeak developer. Finding out what exactly changed and why in the past 8 years is not so easy for someone new. Without someone using it in production on Pharo, there is not enough incentive to keep up with what changes in Pharo. Thereâs a chicken and egg problem there Stephan
I think we all want the same thing: being able to move quickly. It is just not clear how to do that. I saw that you tried a complex scenario in https://pharo.manuscript.com/f/cases/22626/Should-not-hardcode-CmdCommandAbo... - I would not even known how to do that, I think.
On 4 Nov 2018, at 15:35, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Just to share my pain with you. Try to change something in the API of Commander? I think that it will be nearly impossible. Because Iceberg/Calypso depend on Commander and they are all managed in different repositories. So it means - fork each - probably introduce automatic deprecation - do a PR for each of the subprojects (it means identify for each one if we should work on dev or master and being able to checkout the correct version which is not always possible) - then waits.....that may be each of the PR got integrated - now you lost total focus - if one day you recover what you were doing then and only then you may finish your change.
Good luck.
So to me the message is clear: stay away. And this is what I'm doing. We are damaging our agility on the altar of a pseudo modularity.
So this is why I will focus on my tiny, uninteresting side projects. Stef On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Sven
I agree with you. Ideally we would like to have much better tooling and process. Now the last time we discussed with Guille and Pablo about it: they estimated that this is over one year of work. And right now we do not have this engineering time to invest on this because other fronts need to be addressed. Still this is really slowing us. This is simple: I stopped thinking to improve something that touches external packages. So I will not work on the trivial changes that would improve Calypso/Iceberg. Why? Because this is tedious, boring, not rewarding. So yes we can do easily with iceberg simple fix on not external packages but as soon as - you need to load latest dev version (which can be a different one than the current one) - update your repo - fix - do a PR - .... wait for its integration
So at the end we as a community can ask ourselves what is the reward model for such shitty work? And also what are we ready to give so that Pharo maintainers do such boring job.
Right now without really doing it consciously I see myself doing either stupid fix or working on side projects and this is not a good long term approach because the core of Pharo needs a lot of work.
Stef On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 2 Nov 2018, at 12:01, Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers.
I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos.
I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions.
Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
My problem is that this is a trivial change and I could fix everything in 2 min. Now I cannot. On Sun, Nov 4, 2018 at 11:43 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
I think we all want the same thing: being able to move quickly. It is just not clear how to do that.
I saw that you tried a complex scenario in https://pharo.manuscript.com/f/cases/22626/Should-not-hardcode-CmdCommandAbo... - I would not even known how to do that, I think.
On 4 Nov 2018, at 15:35, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Just to share my pain with you. Try to change something in the API of Commander? I think that it will be nearly impossible. Because Iceberg/Calypso depend on Commander and they are all managed in different repositories. So it means - fork each - probably introduce automatic deprecation - do a PR for each of the subprojects (it means identify for each one if we should work on dev or master and being able to checkout the correct version which is not always possible) - then waits.....that may be each of the PR got integrated - now you lost total focus - if one day you recover what you were doing then and only then you may finish your change.
Good luck.
So to me the message is clear: stay away. And this is what I'm doing. We are damaging our agility on the altar of a pseudo modularity.
So this is why I will focus on my tiny, uninteresting side projects. Stef On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Sven
I agree with you. Ideally we would like to have much better tooling and process. Now the last time we discussed with Guille and Pablo about it: they estimated that this is over one year of work. And right now we do not have this engineering time to invest on this because other fronts need to be addressed. Still this is really slowing us. This is simple: I stopped thinking to improve something that touches external packages. So I will not work on the trivial changes that would improve Calypso/Iceberg. Why? Because this is tedious, boring, not rewarding. So yes we can do easily with iceberg simple fix on not external packages but as soon as - you need to load latest dev version (which can be a different one than the current one) - update your repo - fix - do a PR - .... wait for its integration
So at the end we as a community can ask ourselves what is the reward model for such shitty work? And also what are we ready to give so that Pharo maintainers do such boring job.
Right now without really doing it consciously I see myself doing either stupid fix or working on side projects and this is not a good long term approach because the core of Pharo needs a lot of work.
Stef On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 2 Nov 2018, at 12:01, Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers.
I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos.
I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions.
Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
Hi norbert I'm not offended and we can talk. I'm just saying that OUR reality is a lot more complex that managing a separate project. Just today I stopped fixing things in Pharo (Smalltalk ui icons everywhere) just because this is a pain to fix several subprojects. Net result: no improvement. Stef On Fri, Nov 2, 2018 at 12:02 PM Norbert Hartl <norbert@hartl.name> wrote:
Hi
Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi
Pay attention the following email is not nice and politically correct but it is important for the speed of improvements in Pharo.
thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too.
I think that we are doing our best when dealing with subproject code. Now if we are forced to publish each little changes on each subproject and wait that something gets integrated into each subproject, then I would prefer to stop Pharo and do something else. We cannot ask someone to stop in the middle of a massive super boring and feel like shit cleaning in addition to stop and please publish a PR and wait that it gets integrated and wait that Pharo integrates the new version. Let us be a bit serious and pro here.
I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days.
Or we should drop subprojects. Because changing Pharo is getting a painful. Imagine just a change cross cutting several subprojects. For example, I did not fix the use of deprecated classes in Iceberg because I got distracted by the where is the project hosted and I was not connected on a good web connection. I changed calypso and published to calypso but if the feedback loop is too long it means that we will prefer to work on our own projects (because we have also our own projects and there velocity is high and attractive).
I think that with github support this is simple to get the changes. Finally I heard that large companies developing large projects using github are managing one single repo: no subprojects, with their own PR and sync. And us little guys with our super clever brains we will succeed adding more constraints on the table. How bold are we. I'm impressed by such level of arrogance. This is why I do not like that Pharo gets managed in various repo because it kills us.
Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee???
Norbert
Stef On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert@hartl.name> wrote:
Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Norbert,
On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it.
The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble.
Norbert,
I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more.
Could you please test ?
The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch.
Norbert
participants (11)
-
Ben Coman -
Chris Muller -
Esteban Lorenzano -
Esteban Maringolo -
Nicolas Cellier -
Norbert Hartl -
Sean P. DeNigris -
Stephan Eggermont -
Stephane Ducasse -
Sven Van Caekenberghe -
Tim Mackinnon