Cannot use Zinc in Pharo7 anymore

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Cannot use Zinc in Pharo7 anymore

NorbertHartl
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
Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Sven Van Caekenberghe-2


> On 1 Nov 2018, at 14:38, Norbert Hartl <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Sven Van Caekenberghe-2
Norbert,

> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Sven Van Caekenberghe-2


> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Norbert,
>
>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

NorbertHartl
Hi,


> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
>
>
>
>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Norbert,
>>
>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

NorbertHartl
In reply to this post by Sven Van Caekenberghe-2


> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
>
>
>
>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Norbert,
>>
>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Stephane Ducasse-3
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 <[hidden email]> wrote:

>
>
>
> > Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
> >
> >
> >
> >> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
> >>
> >> Norbert,
> >>
> >>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

NorbertHartl
Hi

> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
>
> 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 <[hidden email]> wrote:
>>
>>
>>
>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
>>>
>>>
>>>
>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
>>>>
>>>> Norbert,
>>>>
>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
>>
>>
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Sven Van Caekenberghe-2


> On 2 Nov 2018, at 12:01, Norbert Hartl <[hidden email]> wrote:
>
> Hi
>
>> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
>>
>> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
>>>>
>>>>
>>>>
>>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
>>>>>
>>>>> Norbert,
>>>>>
>>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

NorbertHartl


Am 02.11.2018 um 12:23 schrieb Sven Van Caekenberghe <[hidden email]>:



On 2 Nov 2018, at 12:01, Norbert Hartl <[hidden email]> wrote:

Hi

Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:

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 <[hidden email]> wrote:



Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:



On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:

Norbert,

On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Sean P. DeNigris
Administrator
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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Nicolas Cellier
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" <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Sean P. DeNigris
Administrator
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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Stephane Ducasse-3
In reply to this post by NorbertHartl
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 <[hidden email]> wrote:

>
> Hi
>
> > Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
> >
> > 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 <[hidden email]> wrote:
> >>
> >>
> >>
> >>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
> >>>
> >>>
> >>>
> >>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
> >>>>
> >>>> Norbert,
> >>>>
> >>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
> >>
> >>
> >>
> >>
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Stephane Ducasse-3
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> wrote:

>
>
>
> > On 2 Nov 2018, at 12:01, Norbert Hartl <[hidden email]> wrote:
> >
> > Hi
> >
> >> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
> >>
> >> 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 <[hidden email]> wrote:
> >>>
> >>>
> >>>
> >>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
> >>>>
> >>>>
> >>>>
> >>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
> >>>>>
> >>>>> Norbert,
> >>>>>
> >>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Stephane Ducasse-3
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 <[hidden email]> 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 <[hidden email]> wrote:
> >
> >
> >
> > > On 2 Nov 2018, at 12:01, Norbert Hartl <[hidden email]> wrote:
> > >
> > > Hi
> > >
> > >> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
> > >>
> > >> 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 <[hidden email]> wrote:
> > >>>
> > >>>
> > >>>
> > >>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
> > >>>>>
> > >>>>> Norbert,
> > >>>>>
> > >>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Tim Mackinnon

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>>> On 2 Nov 2018, at 12:01, Norbert Hartl <[hidden email]> wrote:
>>>>
>>>> Hi
>>>>
>>>>> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Norbert,
>>>>>>>>
>>>>>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
>>>
>>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Sven Van Caekenberghe-2
In reply to this post by Stephane Ducasse-3
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-CmdCommandAborted - I would not even known how to do that, I think.

> On 4 Nov 2018, at 15:35, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>>> On 2 Nov 2018, at 12:01, Norbert Hartl <[hidden email]> wrote:
>>>>
>>>> Hi
>>>>
>>>>> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Norbert,
>>>>>>>>
>>>>>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
>>>
>>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Stephan Eggermont-3
In reply to this post by Tim Mackinnon
Tim Mackinnon <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Cannot use Zinc in Pharo7 anymore

Stephane Ducasse-3
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> 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-CmdCommandAborted - I would not even known how to do that, I think.
>
> > On 4 Nov 2018, at 15:35, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >>>
> >>>
> >>>
> >>>> On 2 Nov 2018, at 12:01, Norbert Hartl <[hidden email]> wrote:
> >>>>
> >>>> Hi
> >>>>
> >>>>> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <[hidden email]>:
> >>>>>
> >>>>> 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 <[hidden email]> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <[hidden email]>:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <[hidden email]> wrote:
> >>>>>>>>
> >>>>>>>> Norbert,
> >>>>>>>>
> >>>>>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <[hidden email]> 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
> >>>
> >>>
> >
>
>

12