On Wed, 2024-05-01 at 22:20 +0200, Michael Käppler wrote: > > > There is one caveat here that I would like to mention: During initial > > testing in my fork, one test job unexpectedly hang during a lilypond > > execution, using 100% CPU and eventually being killed after 60 minutes. > > Subsequent runs were fine, so this needs to be monitored and > > investigated if it happens again... > > Do you have a clue what was happening there?
No, nothing conclusive. > > As noted in the MR summary, switching to Ubuntu 22.04 will give us > > testing with the more recent Guile 3.0.7, and I would like to bump the > > requirement to that version, after the switch had some time to settle. > > Likewise I think we should bump the requirement to Texinfo 6.8 (which > > will allow us to drop quite some compatibility code in lilypond.init) > > and Python 3.10 (because Python scripts are notoriously easy to break > > if only tested with more recent interpreter versions). > > > > > > I'm not sure if I get what you say about the Python scripts. > "Python scripts are notoriously easy to break > if only tested with more recent interpreter versions" - you mean > backwards-incompatible changes > would not be noticed? Yes, in my experience it's very hard to claim a script works with a given Python version without actually testing it. Given that most developers will be on newer distributions, our CI is effectively our minimum Python requirement. > Just out of interest, what is the reason that we use different environments > for CI and > for doing releases? As an example, we are using Guile 3.0.9 now for the > releases and Ubuntu 22.04 will have > only 3.0.7. For releases, we have to build all dependencies ourselves, including Guile, on all supported platforms (Linux, macOS, cross-compilation for Windows). Jonas P.S.: your emails are really hard to reply to in text-only mode, sorry for the partially mangled quotation; I'm not sure if that's your messages containing a weird formatting or my mail client acting up...
signature.asc
Description: This is a digitally signed message part
