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 <stepharo.s...@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.s...@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 <s...@stfx.eu> wrote: >>> >>> >>> >>>> On 2 Nov 2018, at 12:01, Norbert Hartl <norb...@hartl.name> wrote: >>>> >>>> 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??? >>> >>> 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 <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 >>> >>> >
