Fixing regressions and serious issues

[Jean Abou Samra]

Hi,

In https://lists.gnu.org/archive/html/lilypond-devel/2022-05/msg00099.html,
we talked about targeting the end of this year for the next
stable release. That probably means branching around
the beginning of September, right? I'd like to call
for attention on the regressions we have
<https://gitlab.com/lilypond/lilypond/-/issues/?label_name%5B%5D=Regression>
as well as some other serious things that should go
into this release: basically, (assuming branching in September)
there is a month and a half left to take care of those.
This is not all that long if not very short, especially since
some people (like me) tend to be less active in August.

Dan and Jonas deserve thanks for having both worked on some of
these recently. As you might have noticed, much of my work lately
was also dedicated to fixing regressions. But there are quite
a number of them remaining, and a they make a lot of work in
total. So, if you're wondering what to contribute next, please
consider putting in some time into one of these.

Specifically, these seem significant to me:


* Cairo anyone? What's the status of
  https://gitlab.com/lilypond/lilypond/-/merge_requests/913?
  Not really a blocker, but I thought the plan was to
  integrate Cairo in the official binaries for this stable
  release.


* “Heisen-crashes on Windows with large scores”

  https://gitlab.com/lilypond/lilypond/-/issues/6361

  A nasty and poorly understood GC problem on Windows,
  needs some tough debugging.


* “GUILE 2.2 doesn't provide source locations”

  https://gitlab.com/lilypond/lilypond/-/issues/5992

  Needs figuring out if executing Scheme code with
  `compile` is OK performance-wise and how to get
  it to display source location info.


* “\markup \score in \paper can no longer have \layout block”

  https://gitlab.com/lilypond/lilypond/-/issues/6364

  Needs investigating what broke with Guile 2 and its
  module system.


* “No cropping when using lilypond-book-preamble include”

  https://gitlab.com/lilypond/lilypond/-/issues/6235

  Needs either reverting to the old behavior or a Changes
  entry and a convert-ly rule.


* “\bar creates a spurious staff”

  https://gitlab.com/lilypond/lilypond/-/issues/6341


* “Unterminated beam causes intimidating programming errors"

  https://gitlab.com/lilypond/lilypond/-/issues/6372


* “Changed behavior of staves with differing repeat structures
  breaks doc example"

  https://gitlab.com/lilypond/lilypond/-/issues/6373

  Needs at least amending a doc example, but first checking
  that behavior changes are unlikely to be noticed often,
  and if not, add a Changes entry and/or a compilation warning
  if staves have different repeat structures.



Again, if you have some energy, fixing one of these
won't be wasted time.

Thanks,
Jean