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