lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blockers for Guile 2.2


From: Jonas Hahnfeld
Subject: Re: Blockers for Guile 2.2
Date: Sun, 27 Feb 2022 08:57:50 +0100
User-agent: Evolution 3.42.3

Am Sonntag, dem 27.02.2022 um 01:04 +0100 schrieb Han-Wen Nienhuys:
> On Sat, Feb 26, 2022 at 2:02 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > > while we make work slower for folks that work on large
> > > scores and can afford to side-install Guile 1.8. It also makes
> > > development slower for ourselves. Yes, that means some of us will
> > > develop on a different platform than many users. This has been the
> > > case since we started supporting OSX and Windows.
> > 
> > I slightly disagree, running on a different platform is not the same as
> > running with a completely different set of dependencies. And we know
> > Guile 2.2 is completely different from 1.8.
> 
> > > Everyone who is passionate about Guile 2.2 can develop against Guile 2.2.
> > 
> > So to be clear here: You would release official binaries with Guile 2.2
> > and rely on a subset of developers to fix the bugs while you make it
> > clear that you don't want to do that? Why would anybody accept that
> > job?
> 
> I never said I don't want to fix Guile 2.2 bugs, and you should know
> as I spent lots and lots of time debugging #6218.  I also said I
> support moving CI to 2.2, so any MR would pass against 2.2.
> 
> I am just asking to not drop 1.8 support.

Ok, so let me try to understand the motivation here: It's not for the
official binaries, where you want to move away from GUB so it would be
Guile 2.2 only. Neither about distributions, which are looking into or
have already switched to Guile 2.2. This leaves "power users" that
compile LilyPond on their own, with Guile 1.8. Not sure if it's worth
complicating our development lives for what will be a transition period
anyway.
For your local development, if you care about things working with Guile
2.2, you'll have to test at least the final version of a patch with
both versions. So I can only assume that you expect a time saving to
come from hacking with Guile 1.8 during prototype?

> Most of the work we do isn't actually about Guile anyway,
> 
> $ git log --since 2022/01/01 | grep ^commit|wc
>     257     514   12336
> $ git log  --grep=[Gg]uile --since 2022/01/01 | grep ^commit|wc
>       7      14     336

What you're showing is that most commit messages don't mention Guile.
IMO the more relevant metric is how many commits touch scm/, in
comparison to those that are not purely updates of the documentation:

$ git log --oneline --since 2022-01-01 -- flower/ lily/ ly/ scm/ | wc -l
125
$ git log --oneline --since 2022-01-01 -- scm/ | wc -l
52

One third. Since 2021-01-01 that ratio is closer to every second.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]