Re: Blockers for Guile 2.2

[Werner LEMBERG]

[First of all: Thanks, Jonas, for releasing 2.22.2 today!]


I guess most people like me lack the skills to give helpful comments,
so they stay silent.  The only part where I can voice an opinion is
the following.

>> Meanwhile, please take a look at reality: Linux distributions are
>> switching to Guile 2.2 for LilyPond, no matter what the state is
>> and what our documentation recommends.  Debian attempted to switch
>> for the stable release 2.22.0 (that is now in Debian stable) and we
>> convinced them to stick to Guile 1.8 more-or-less last minute.
>> Arch Linux switched to using Guile 2.2 twice, but I was able to
>> convince them that they should wait.  Gentoo has an option to build
>> with Guile 2, not sure if it's used by default or up to the user.
>> The package in Fedora continues to use Guile 2.2 IIRC.
>>
>> What this tells me is that we get a split user community if we do
>> nothing.  If we want to avoid that and pro-actively test and fix
>> issues, we have to switch *now* and lead the transition.

Jonas, you are doing a wonderful job by working on the Guile 2.2
transition.  However, it seems to me that it will still take a
significant time until we have something that can be used for daily
work.  In particular, we can't tell non-developers "Please use the
current development version, which works very reliably" and introduce
a severe slowness at the same time.

As far as I can see, there are two types of testers of development
versions.

(1) The casual user that needs this and that feature fixed, and who
    isn't satisfied with the stable release and curious enough to
    update.  I think that we are going to lose a significant portion
    of people if development versions are much slower for no immediate
    benefits.

(2) The hardcore development team and related friends, who are willing
    to bear the slowness, ironing out issues on the way to recent
    Guile versions.

Do we accept the loss of people in the (1) group?  These people test
everything of LilyPond's changes except Guile.

Otherwise I could imagine to do the following.

(a) Incorporate Guile 1.8 into the LilyPond tarball to produce
    releases without fearing that distributions eliminate LilyPond
    packages.

(b) Produce development releases with Guile 1.8 for people in the (1)
    group, probably with GUB.  Recent MacOS users would have to use
    MacPorts.

(c) Produce development releases with Guile 2.2 for people in the (2)
    group with Jonas' build system.

I'm not sure how much of my suggestion can be automated to reduce
manual work on it.


    Werner