Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Samstag, dem 19.02.2022 um 23:05 +0100 schrieb 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 --,

The proposed approach is worse than just doing a GUILE_AUTO_COMPILE
because we need more code to make it happen. More fundamentally, it
doesn't address the cross-compilation setup.

> and if we do, how would Guile 1 interfere with moving code
> around?

It requires testing, and there are constructs such as eval-when that
Guile 1.8 didn't have. Yes, you can work around that, but it will
require more code and even more time.

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

Because I kept it working so far.

> I am like St Thomas and need examples to be convinced by 'many'. Even for
> Cairo there is a solution in GUB.

One example is https://gitlab.com/lilypond/lilypond/-/issues/5831,
another is
https://lists.gnu.org/archive/html/lilypond-devel/2020-08/msg00159.html
where (I think) we shouldn't install the fonts as part of LilyPond's
build system. Both of them would require updates to GUB, which I
honestly don't want to make.

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

It's not only about load, it's about every merge request taking 3x as
long to merge.

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

I don't share your optimism here, neither on "occasional 'hotfix'", "a
month or so", nor "fixing a few things here and there". I predict
things will break, and very quickly if you attempt to do things as
invasive as making byte compilation work.

Jonas

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