Re: Blockers for Guile 2.2

[Luca Fascione]

On Thu, Feb 24, 2022 at 5:44 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:

> I will not reply to most of your message; I suspect that your
> experience comes from a corporate environment where people are paid
> full time to work on software.


It does, yes.


> In my opinion, many of the points are
> simply not relevant in a relatively small community of volunteers, for
> example the release frequency (which is already quite high for an open
> source project I would say). Same for testing, in particular all
> possible combinations of dependencies.
>

Forgive me Jonas, I don't follow. It seems to me any means to improve
the quality of the software development process would be fair game, no?
A better process means all the folks involved maximize the ratio of effort
into the project to results coming out into the hands of users, I don't
understand why this would be undesirable to any community of engineers
no matter whether they write this code because it's their job or their
passion after hours. If anything, I'd think the folks that do it after
hours
would be the most interested in focusing on the fun side and not on the
"fix the boring bugs and regressions" side, no?

> The one thing I want to get straight are the comments about Guile 3.0
> because that claim keeps coming up:
>
> Am Donnerstag, dem 24.02.2022 um 09:13 +0100 schrieb Luca Fascione:
> > [...] 3.0.x [...] seems to be benchmarking with speeds comparable to
> the 1.8.x line
>
> It's important to differentiate between their benchmarks and the real-
> world impact on a complex project like LilyPond. There have been
> preliminary tests and they indicate that it's still a lot slower than
> Guile 1.8 without bytecode. Whether it will be faster than Guile 2.2
> for our use-cases afterwards, I don't know.
>

I see. Cool, I wasn't aware. Great to hear it's already been tested, I
just said
because nobody was talking about it, and HanWen asked folks about the
perspective of the Guile engineers for upcoming evolutions.
Seems pretty clear from a casual browse of their page that they don't
intend to work on 2.2 any longer, and that their efforts are on 3.x now.


> > Given the switch to 2.2 hasn't happened yet, and as I am reading
> > through these emails, it has been a long process, wouldn't moving to
> > 3.0 instead be a better way to capitalize on the effort and push out
> > the next round of this level of pain to a later date?
>
> The question is, would this make things better? Jumping across even
> more versions certainly doesn't promise to be an easier transition.
>

I guess I was looking at it from the opposite end: imagine it makes _this_
transition
a little harder, but then postpones the next one (which will inevitably
come) by several years.
Wouldn't this be an interesting deal for your users? (and engineers, of
course)

I guess I'm saying: say that in 2025 you'll have to go to Guile 3 anyways
(maybe because 2.2.x goes
unsupported or whatever reason). What tells us that change will be easier
than this?
On the other hand, if you were to adopt 3 today, you can gradually upgrade
it as you go and try and stay on the 3.x train
(maybe you do a tick/tock thing where you pull guile up every other version
bump, as a random example).
Or anyways be on a supported runtime for a few years longer.

Now of course, if instead of this being a "little" harder, it is in fact a
"lot" harder, none of what I'm saying makes any sense.
I don't know the specifics, but I know the pattern can reduce effort  and
improve the "fun" to "drudge" ratios, when the conditions are right.

Cheers,
L


>