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 <norb...@hartl.name> wrote: > > > > > Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <s...@stfx.eu>: > > > > > > > >> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <s...@stfx.eu> wrote: > >> > >> Norbert, > >> > >>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <s...@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 > > > > >
