Hi > Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.s...@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 <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 >> >> >> >> >> >
