Re: Blockers for Guile 2.2

[Jean Abou Samra]

Le 19/02/2022 à 22:43, Jonas Hahnfeld a écrit :
> Am Samstag, dem 19.02.2022 um 21:34 +0100 schrieb Jean Abou Samra:
> > Le 19/02/2022 à 21:00, Jonas Hahnfeld a écrit :
> > > I'm firmly convinced that the order must be
> > > 1. only test with Guile 2.2 in CI
> > > 2. make configure only look for Guile 2.2 by default
> > > 3. do a release with Guile 2.2 only
> > > 4. unless emergency happens, drop all code related to Guile 1.8 very
> > > soon after
> > I disagree with 'very soon after' in point 4. Is this code
> > really hurting? We don't have so much of it as far as I can
> > see.
> All "guile-2" in scm/, GUILEV2 in lily/, and a number of configure
> checks. It will be significantly easier to restructure all of our
> Scheme code without that.



I am not sure about that. It's unclear to me whether we're
going to have to move stuff around in the end -- see the helpful
reply from Olivier Dion this evening on guile-user/guile-devel --,
and if we do, how would Guile 1 interfere with moving code
around?



> Plus, your plan of keeping code for Guile 1.8 doesn't work / make sense
> without keeping GUB working. That is far more complicated and prevents
> many future changes.



Right now, it is in a working state. I am like St Thomas
and need examples to be convinced by 'many'. Even for
Cairo there is a solution in GUB.

To be clear, I'm not happy about keeping it around, but
I very much think we shouldn't actively drop it until we
have a state that resembles what we eventually want to
call stable. Because we don't know what problems are going
to pop up with shipping bytecode.



> > I find it too risky to lock ourselves into Guile 2 in
> > a state where a stable release would not be satisfactory
> > (see also below). Plus, a number of problems have been popping up
> > with the new binaries. It's great that you're fixing them
> > at the speed of light (thanks!), but I'm not convinced by
> > waiting only shortly after a new release to call it good
> > to go. Would it consume excessive CI minutes if we tested
> > with both Guile 1 and 2 for some time? If so, I would
> > suggest having optional jobs with Guile 1, basically swapping
> > the current roles.
> Again, this doesn't make sense: If we want to keep Guile 1.8 working,
> the jobs must be mandatory. So we're talking at least twice the CI
> minutes, in practice much more because frog can only run one job at a
> time.



Would that be an acceptable load on the CI infrastructure?

If not, I wouldn't find too much of an issue with optional jobs.
Right now, we want to keep Guile 2 working, the jobs are
optional, and it keeps working thanks to an occasional
'hotfix'. Those fixes don't even need to be made while we are
in the state where LilyPond still accepts being configured
with Guile 1. If the transition only takes a month or so,
it should normally remain possible to roll back to Guile 1,
fixing a few things here and there. It is actively dropping
code supporting Guile 1 that I object to at this point.


Jean