Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Donnerstag, dem 24.02.2022 um 18:25 +0100 schrieb 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?

Exactly, and making a new release every 10 days is certainly not on the
top of my "fun side". Neither is extending the test suite in order for
it to reliably catch all possible regressions that could arise from
supporting Guile 1.8 and 2.2 in parallel.
 
> > > 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?

Testing. You can already run with 3.0 if you really want to. Not
everything works and you get drowned by warnings, but the changes will
be smaller than from 1.8 to 2.2. What would be more difficult, though,
is making LilyPond with *three* versions of Guile in the same code.

> 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.

I expect that support for Guile 3.0 will follow after we drop 1.8 and
only support version 2.2, and it will be relatively smooth. That said,
requiring this to happen now will delay the transition away from GUB
and Guile 1.8 even 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.

I don't agree. Projects are the most fun if they are clearly scoped and
don't drag on "forever". We clearly failed that objective already, so
why keep extending?

Jonas

signature.asc
Description: This is a digitally signed message part