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