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