Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Samstag, dem 26.02.2022 um 13:51 +0100 schrieb Han-Wen Nienhuys:
> On Wed, Feb 23, 2022 at 12:36 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > 
> > > * The concern over CI minutes seems like it's the least important: we
> > > can buy more computing power (I'm happy to sponsor), and is the
> > > duration of CI much of a concern today?
> > 
> > In the past, you've complained the loudest about slow CI builds for
> > merging changes...
> 
> A build for 2.2 and 1.8 could be run in parallel, I think?

Yes, but it's still going to be slow because we have exactly one very
fast runner.

> > > I don't think we have to do the doc build across both 1.8 and 2.2, for 
> > > example.
> > 
> > I think we do because a full doc build provides coverage and stress
> > testing that is unachieved by the regression tests.
> 
> The doc build is exactly the same as the regtest: a lot of small files
> that are rendered mostly in per-system mode (rather than per page).
> It's just more of the same, so you get better coverage for small
> windows of time where objects aren't GC protected.
> 
> Also, you make it seem as if perfect coverage is the only alternative
> to scrapping the code altogether. I think that is a false dilemma.
> 
> > > * We're talking about the impact of (the lack of) byte compilation on
> > > users, but we haven't discussed the impact on ourselves: the startup
> > > slowness affects our every debug/edit cycle, and byte compilation is
> > > impractical because we change scm files often (by virtue of checking
> > > out other branches).
> > 
> > The same happens for C++ files, you also have to recompile. But it's
> > true that editing scm files isn't for free anymore.
> 
> The Scheme compilation felt much slower, and for C++ ccache takes away
> a lot of the pain of recompiles. It also appears to be
> single-threaded? I admit not having timed it in detail.

Yes, GUILE_AUTO_COMPILE=1 is single-threaded which is why it will never
be the default.

> > > If we need to kill 1.8 support because it blocks
> > > something important, then so be it, but given the impact on lilypond
> > > development, I'd try to postpone it if possible.
> > 
> > So, you propose that development continues on Guile 1.8, but we
> > advertise that we consider Guile 2.2 ready for production use? I don't
> > think that makes for a great user experience if we let them find
> > problems... Also "postpone" up to what point?
> 
> If we drop 1.8 support now, we can drop just a tiny sliver of
> complexity (places marked GUILEV2 and guile-2 in C++ and Scheme
> respectively),

I think you're underestimating the gain here.

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

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