Re: branching stable/2.22?
Hi, > Le 24 août 2020 à 13:46, Jonas Hahnfeld a écrit : > > Am Montag, den 24.08.2020, 12:56 +0200 schrieb Jean Abou Samra: >> Hi, >> >>> Le 24 août 2020 à 08:30, Jonas Hahnfeld a écrit : >>> >>> Am Sonntag, den 23.08.2020, 23:44 +0200 schrieb Jean Abou Samra: Maybe we could try to release 2.20.1 with Python 3? >>> >>> That would mean porting 50+ commits which sounds like a bad idea and >>> even gets worse because of the reformatting in master. The latter >>> implies that any bug fix made in master will result in merge conflicts. >>> Plus I don't understand the proposal if you're at the same time saying >>> that the scripts are fragile. By that logic, why would we backport such >>> extensive changes and claim they're stable? >> >> Right, I was oblique: the scripts are fragile at present, so branching >> release/2.22 now is no good in my opinion, but hopefully we can stabilize >> them faster than we stabilize LilyPond as a whole, and have that in 2.20.1 >> or 2.20.2. >> >> Can you explain why porting 50 commits from master to 2.20 is a bad idea? > > I think it's a bad idea because it goes against my basic understanding > that only bug fixes should be ported a stable branch. This situation is special anyway: we did a release that is from the start outdated with respect to Python support. All I'm saying is that porting this to 2.20 would be better than releasing 2.22 in a hurry, for the reasons that David and I mentioned. So... > Here's the total > number of commits in stable/2.20 since branching: > [...] >> If we port all Python related-commits (including the reformatting), there >> won't be any merge conflicts, or am I being dense somehow? > > [...] > Being the individual with the most commits in there during the cycle, I > strongly advise against taking all of this for a minor stable release. ... so since that appears unpossible, I guess we'd just let distros drop LilyPond. >> I do understand that having LilyPond 2.20.0 support exclusively Python 2 but >> 2.20.1 be Python 3 only feels weird. However, I value the interest of the >> average user more than that of packagers. Neither Python 3 nor Guile 2 is a >> breaking change from the user's point of view. If having LilyPond 2.20.1 (or >> 2.20.2) support Python 3 is not feasible, I think we should just let >> distributions drop LilyPond (see below). I'm not happy about it, but this >> is, in my opinion, preferable to making a stable release, in a hurry, that >> will contain more bugs and few user-facing changes. >> Why Guile 2? If it's still imperfect and slower, we don't want to make it the default in the binaries at lilypond.org, do we? So how will the situation be different from 2.20? Sorry, I must be missing something obvious here... I don't understand you. >>> >>> At least in my book, it's not about changing the default but at least >>> making it possible for distributions to compile with Guile 2.x instead >>> of just throwing LilyPond out. >> >> Does this mean that we'll receive bug reports that won't be reproducible by >> others because they'll actually be related to Guile 2? In my opinion, the >> distributions just throwing out LilyPond is better. >> >> Additionally, the sh installers are recommended by the official website over >> distribution package managers. >>> I don't think we'll get testing from distributions until we declare a >>> way to stabilize. >> >> We're speaking from different points of view here: in my book, our main >> source of testing is our development and beta releases brought to users >> through installers. I mean that LilyPond 2.22 should introduce full support >> for Guile 2 with byte compilation, probably dropping Guile 1 support too, >> and we get Guile 2 testing from those who try out the betas. > > I seriously doubt you'll get that for 2.22 next year. That date was a shot in the dark intended at starting the discussion. See also below. Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup: >> I'd like to ask what it would take in principle to branch stable/2.22 >> and what others think about this. > > I don't see that this is a good point of time. > There has been an influx of badly tested changes to the build system and > directory setup and the web pages that has to stabilise and result in a > workable version of LilyPond. I don't see the point in branching a > "stable" branch if there is so much in a destabilised state: you'd have > to cherry-pick loads of stuff from the unstable branch as it comes in. [Jonas] I fully agree ... and so do I (for what my opinion's worth, really) ... [Jonas] and I should have been more clear that I don't expect the branch to happen in the next week. The point was to find out what it would take because just waiting for some unspoken condition to become true is not exactly going to happen without some effort.
Re: maintaining lilypond git repository on github
Am Mittwoch, den 19.08.2020, 19:42 +0200 schrieb Jonas Hahnfeld: > Am Dienstag, den 18.08.2020, 20:55 +0200 schrieb Jonas Hahnfeld: > > Looks like the previous updates didn't purge removed branches, at least > > there are still a bunch that are neither at Savannah nor GitLab. I'd > > propose we delete all but the "protected branches" (GitLab terminology; > > master, translation, stable/*, release/unstable) because these are the > > refs that are going to be mirrored from GitLab. > > I'll go ahead with this one next week unless I hear objections until > then. And gone (but fear not, they're still on Savannah and GitLab). For reference, I issued the following: $ git push --delete github $(git branch -a | grep github/dev | sed "s/^\W*remotes\/github\///") $ git push --delete github archive/macos-lilypad archive/web archive/web-gop which brings us down to 21 branches: $ git branch -a | grep github | sed "s/^\W*remotes\/github\///" master release/unstable stable/0.0 stable/1.0 stable/1.2 stable/1.4 stable/1.6 stable/1.8 stable/2.0 stable/2.10 stable/2.12 stable/2.14 stable/2.16 stable/2.18 stable/2.2 stable/2.20 stable/2.4 stable/2.6 stable/2.8 translation translation-staging Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: branching stable/2.22?
Jonas Hahnfeld writes: > Am Montag, den 24.08.2020, 12:56 +0200 schrieb Jean Abou Samra: >> >> Right, I was oblique: the scripts are fragile at present, so >> branching release/2.22 now is no good in my opinion, but hopefully >> we can stabilize them faster than we stabilize LilyPond as a whole, >> and have that in 2.20.1 or 2.20.2. >> >> Can you explain why porting 50 commits from master to 2.20 is a bad idea? > > I think it's a bad idea because it goes against my basic understanding > that only bug fixes should be ported a stable branch. Here's the total > number of commits in stable/2.20 since branching: > $ git log --oneline release/2.20.0-1...release/2.19.65-1 | wc -l > 588 > > Sounds high at first, but most of that was translations, ie > $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- $(ls | > grep -vE "Documentation|po") | wc -l > 268 > If only focusing on actual code changes: > $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- flower/ > lily/ ly/ python/ scm/ scripts/ | wc -l > 198 > with the majority in "core" LilyPond: > $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- lily/ ly/ scm/ | > wc -l > 148 It's worth stressing that the 2.20 branch persisted much longer before the 2.20 release than planned. So there were also some feature cherry-picks in order to avoid the situation that the 2.20 release would be "outdated from the start" with regard to some "must-have" features that would be expected to be common in suggested code on the mailing lists. So 2.20's history in some way reflects how to muddle through in a situation that became a lot different from planning. It's not really a template for how things should work. -- David Kastrup
Re: branching stable/2.22?
Am Montag, den 24.08.2020, 12:56 +0200 schrieb Jean Abou Samra: > Hi, > > > Le 24 août 2020 à 08:30, Jonas Hahnfeld a écrit : > > > > Am Sonntag, den 23.08.2020, 23:44 +0200 schrieb Jean Abou Samra: > > > Hi, > > > > > > (Sorry about the strange reply style.) > > > > > > > On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld wrote: > > > > I'd like to ask what it would take in principle to branch stable/2.22 > > > > and what others think about this. > > > > > > > > Personally I'm convinced that creating the branch and only picking bug > > > > fixes from master is the only guaranteed way to stabilize. Now you > > > > might say that there were only few unstable releases (AFAICT there was > > > > 2.19.65 before branching stable/2.20). However, I think there are > > > > already quite some user-facing changes and also the switch to Python 3. > > > > With Python 2.x being EOL since January, it's only a matter of time > > > > until Linux distributions and BSDs want to drop that, and it > > > > would be > > > > unfortunate if that put a (temporary) end to providing LilyPond for > > > > their users. If we had release candidates or even a stable version > > > > until then, it would definitely help. > > > > > > Maybe we could try to release 2.20.1 with Python 3? > > > > That would mean porting 50+ commits which sounds like a bad idea and > > even gets worse because of the reformatting in master. The latter > > implies that any bug fix made in master will result in merge conflicts. > > Plus I don't understand the proposal if you're at the same time saying > > that the scripts are fragile. By that logic, why would we backport such > > extensive changes and claim they're stable? > > Right, I was oblique: the scripts are fragile at present, so branching > release/2.22 now is no good in my opinion, but hopefully we can stabilize > them faster than we stabilize LilyPond as a whole, and have that in 2.20.1 or > 2.20.2. > > Can you explain why porting 50 commits from master to 2.20 is a bad idea? I think it's a bad idea because it goes against my basic understanding that only bug fixes should be ported a stable branch. Here's the total number of commits in stable/2.20 since branching: $ git log --oneline release/2.20.0-1...release/2.19.65-1 | wc -l 588 Sounds high at first, but most of that was translations, ie $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- $(ls | grep -vE "Documentation|po") | wc -l 268 If only focusing on actual code changes: $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- flower/ lily/ ly/ python/ scm/ scripts/ | wc -l 198 with the majority in "core" LilyPond: $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- lily/ ly/ scm/ | wc -l 148 > If we port all Python related-commits (including the reformatting), there > won't be any merge conflicts, or am I being dense somehow? Consider: $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- python/ | wc -l 22 vs $ git log --oneline HEAD...release/2.19.65-1 -- python/ | wc -l 115 and $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- scripts/*.py | wc -l 5 vs $ git log --oneline HEAD...release/2.19.65-1 -- scripts/*.py | wc -l 67 Being the individual with the most commits in there during the cycle, I strongly advise against taking all of this for a minor stable release. > I do understand that having LilyPond 2.20.0 support exclusively Python 2 but > 2.20.1 be Python 3 only feels weird. However, I value the interest of the > average user more than that of packagers. Neither Python 3 nor Guile 2 is a > breaking change from the user's point of view. If having LilyPond 2.20.1 (or > 2.20.2) support Python 3 is not feasible, I think we should just let > distributions drop LilyPond (see below). I'm not happy about it, but this is, > in my opinion, preferable to making a stable release, in a hurry, that will > contain more bugs and few user-facing changes. > > > > > The same can of course happen with Guile, but that situation has been > > > > going on for years. Furthermore, it's at least possible to compile and > > > > use current master with Guile 2.x, even if slower. In my understanding, > > > > things are getting better but properly integrating byte compilation is > > > > still a good amount of work that nobody could give a deadline on. > > > > > > > > WDYT? > > > > > > [Han-Wen] I think that both Python 3 support and usable (if imperfect) > > > GUILE 2 support is a strong argument for releasing a new stable version > > > soon. > > > > > > Why Guile 2? If it's still imperfect and slower, we don't want to make it > > > the default in the binaries at lilypond.org, do we? So how will the > > > situation be different from 2.20? Sorry, I must be missing something > > > obvious here... I don't understand you. > > > > At least in my book, it's not about changing the default but at least > > making it possible for distributions to compile with Guile 2.x instead > > of just throwing
Re: branching stable/2.22?
Hi, > Le 24 août 2020 à 08:30, Jonas Hahnfeld a écrit : > > Am Sonntag, den 23.08.2020, 23:44 +0200 schrieb Jean Abou Samra: >> Hi, >> >> (Sorry about the strange reply style.) >> >>> On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld wrote: >>> I'd like to ask what it would take in principle to branch stable/2.22 >>> and what others think about this. >>> >>> Personally I'm convinced that creating the branch and only picking bug >>> fixes from master is the only guaranteed way to stabilize. Now you >>> might say that there were only few unstable releases (AFAICT there was >>> 2.19.65 before branching stable/2.20). However, I think there are >>> already quite some user-facing changes and also the switch to Python 3. >>> With Python 2.x being EOL since January, it's only a matter of time >>> until Linux distributions and BSDs want to drop that, and it would be >>> unfortunate if that put a (temporary) end to providing LilyPond for >>> their users. If we had release candidates or even a stable version >>> until then, it would definitely help. >> >> Maybe we could try to release 2.20.1 with Python 3? > > That would mean porting 50+ commits which sounds like a bad idea and > even gets worse because of the reformatting in master. The latter > implies that any bug fix made in master will result in merge conflicts. > Plus I don't understand the proposal if you're at the same time saying > that the scripts are fragile. By that logic, why would we backport such > extensive changes and claim they're stable? Right, I was oblique: the scripts are fragile at present, so branching release/2.22 now is no good in my opinion, but hopefully we can stabilize them faster than we stabilize LilyPond as a whole, and have that in 2.20.1 or 2.20.2. Can you explain why porting 50 commits from master to 2.20 is a bad idea? If we port all Python related-commits (including the reformatting), there won't be any merge conflicts, or am I being dense somehow? I do understand that having LilyPond 2.20.0 support exclusively Python 2 but 2.20.1 be Python 3 only feels weird. However, I value the interest of the average user more than that of packagers. Neither Python 3 nor Guile 2 is a breaking change from the user's point of view. If having LilyPond 2.20.1 (or 2.20.2) support Python 3 is not feasible, I think we should just let distributions drop LilyPond (see below). I'm not happy about it, but this is, in my opinion, preferable to making a stable release, in a hurry, that will contain more bugs and few user-facing changes. >>> The same can of course happen with Guile, but that situation has been >>> going on for years. Furthermore, it's at least possible to compile and >>> use current master with Guile 2.x, even if slower. In my understanding, >>> things are getting better but properly integrating byte compilation is >>> still a good amount of work that nobody could give a deadline on. >>> >>> WDYT? >> >> [Han-Wen] I think that both Python 3 support and usable (if imperfect) GUILE >> 2 support is a strong argument for releasing a new stable version soon. >> >> Why Guile 2? If it's still imperfect and slower, we don't want to make it >> the default in the binaries at lilypond.org, do we? So how will the >> situation be different from 2.20? Sorry, I must be missing something obvious >> here... I don't understand you. > > At least in my book, it's not about changing the default but at least > making it possible for distributions to compile with Guile 2.x instead > of just throwing LilyPond out. Does this mean that we'll receive bug reports that won't be reproducible by others because they'll actually be related to Guile 2? In my opinion, the distributions just throwing out LilyPond is better. Additionally, the sh installers are recommended by the official website over distribution package managers. >> At any rate, Python 3 support is great, but the scripts are fragile at the >> moment. This is clear from the tracker and the bug-lilypond list. Our Python >> scripts still need fixes in the way we distribute them, plus >> encoding-related issues (I'm planning on tackling the latter point in a >> short period at the end of August, but who knows what that will reveal). > > Could you please point to concrete issues? The distribution of scripts > hasn't changed, so it basically still works the same it did for years > (decades?). I'm writing this with a browser that is too old to view gitlab.com. There is at least https://www.mail-archive.com/bug-lilypond@gnu.org/msg43376.html which looks serious at first sight. >> [Han-Wen] I've been working on the build system (obviously), with in the >> back of my mind having a build that is no longer recursive, but that work >> could be paused for a bit while we prepare for releasing a 2.22. Is there a >> list of problems in the current master that have to be resolved? >> >> Problems are basically popping every week (e.g., info installation, >> translation tools,
PATCHES - Countdown for August 24th
Hello, Here is the current patch countdown list. The next countdown will be on August 26th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !342 Fix doc/ja/customized-drum-notation-in-printed-and-midi-output - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/342 !339 Simultaneous_music_iterator: remove dead code - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/339 !335 Option `anti-alias-factor' only takes positive integers <=8 - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/335 Countdown: !343 fix xref deps for translations - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/343 !340 webserver: Make en the default language - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/340 !338 Fold WWW-1 and WWW-2 targets together - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/338 !336 Remove dependency on netpbm, use ImageMagick - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/336 !332 new command line options `-dpng-width` and `-dpng-height` - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/332 Review: !348 lilypond-book: replace reduce() call with list concatenation - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/348 !347 doc: qualify snippet paths - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/347 !346 Update documentation of requirements - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/346 !345 extract_texi_filenames: fail on not finding include - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/345 !136 Forbid items from taking spanners as X_AXIS parents. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/136 !45 Clarify System break_into_pieces/break substitution interaction - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/45 New: No patches in New at this time. Waiting: !344 WIP: fully qualify doc includes. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/344 !341 Revise gittxt generation - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/341 !204 Move parallel processing to lilypond-book - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/204 *** Regards, James
Re: GSoC 2020 update: (hopefully) final commits made; testing time
> I've reordered and rebased my code, and it is now up to date with > the current master. I've just published the new branch to GitLab as > dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only > nine commits now, instead of over a hundred, and they're ordered in > a way that's hopefully easy to follow. Some more comments. * Who has written the file `glyphnames.json`? It lacks a copyright header. If this is a non-lilypond file copied verbatim, please add a separate file (say, `glyphnames.json.txt`) that gives all the details: author, origin, license, retrieving date, etc. If necessary, a comment should be added to LilyPond's `LICENSE` file. * You also have to mention the non-LilyPond JSON file license in the `LICENSE` file since it is not GPL. * In general, all new files like `scm/name-conversion.scm` need a copyright header similar to other files. Exception are very small, auxiliary files with, say, less then 10 (not too long) lines of data. Werner
Re: GSoC 2020 update: (hopefully) final commits made; testing time
>> At the same time, I'll write docs for my work. I figure I'll make >> nine documentation commits, one for each code change commit. Hmm. Maybe I've misunderstood you. What's actually missing are documentation strings *within* the commits. For example, the commit Add smufl data to feta glyphs & METAFONT logs lacks any further description. In other words, I see a necessity that you amend all of your commits, enriching each of them with detailed documentation that enables a reader to understand what's really going on, then doing a force-push of your branch. This doesn't replace real user documentation, of course, which should be added, too. Werner
Re: GSoC 2020 update: (hopefully) final commits made; testing time
Am Montag, den 24.08.2020, 09:06 +0200 schrieb Werner LEMBERG: > > I've reordered and rebased my code, and it is now up to date with > > the current master. I've just published the new branch to GitLab > as > > dev/lamb/GSoC-2020-final if you'd like to give it a look. It's > only > > nine commits now, instead of over a hundred, and they're ordered in > > a way that's hopefully easy to follow. > > Thanks! > > > At the same time, I'll write docs for my work. I figure I'll make > > nine documentation commits, one for each code change commit. (Of > > course, I may not need one for every commit, but we'll see.) Does > > that sound all right? Would it be better to make yet another > branch > > with the documentation integrated into the main commits? > > I don't see any reason to synchronize the documentation with commits; > it looks like unnecessary work. Maybe others disagree, but I think > you should simply add all of the documentation in a single, separate > commit. > +1 But probably regtests should match the state of their commits. Except if you can add all regtests at the end. Urs > > Werner >
Re: GSoC 2020 update: (hopefully) final commits made; testing time
> I've reordered and rebased my code, and it is now up to date with > the current master. I've just published the new branch to GitLab as > dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only > nine commits now, instead of over a hundred, and they're ordered in > a way that's hopefully easy to follow. Thanks! > At the same time, I'll write docs for my work. I figure I'll make > nine documentation commits, one for each code change commit. (Of > course, I may not need one for every commit, but we'll see.) Does > that sound all right? Would it be better to make yet another branch > with the documentation integrated into the main commits? I don't see any reason to synchronize the documentation with commits; it looks like unnecessary work. Maybe others disagree, but I think you should simply add all of the documentation in a single, separate commit. Werner
GSoC 2020 update: (hopefully) final commits made; testing time
Hi all! First, an apology--I thought the project was due today, the 23rd, but it's actually due next week, on the 31st. Tomorrow is just the first day I can submit the project. Well, better to err on the side of caution! I'd like to finish things up at least three days before the Monday deadline--i.e. Friday--if possible. I've reordered and rebased my code, and it is now up to date with the current master. I've just published the new branch to GitLab as dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only nine commits now, instead of over a hundred, and they're ordered in a way that's hopefully easy to follow. (I made a few changes to the code as I reordered it--removing the vestiges of abandoned ideas, backtracking on a few things I'm unsure of, and ensuring LilyPond compiles correctly at every commit. This means the latest GSoC-2020-final snapshot doesn't match the latest GSoC-2020 snapshot exactly.) I suppose this last week, then, is for testing and docs. I'll figure out how to run the regtests, ensuring I didn't break anything from commit to commit, and write new regtests as necessary, involving the new features, like /smuflglyph. At the same time, I'll write docs for my work. I figure I'll make nine documentation commits, one for each code change commit. (Of course, I may not need one for every commit, but we'll see.) Does that sound all right? Would it be better to make yet another branch with the documentation integrated into the main commits? And, of course, I'll also be working on my blog post, which I've already started writing! I'll let you guys know when it's finished, which will hopefully be in a couple days. Questions, comments, and concerns are welcome as always. Thanks, Owen
Re: branching stable/2.22?
Am Sonntag, den 23.08.2020, 23:44 +0200 schrieb Jean Abou Samra: > Hi, > > (Sorry about the strange reply style.) > > On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld wrote: > > I'd like to ask what it would take in principle to branch stable/2.22 > > and what others think about this. > > > > Personally I'm convinced that creating the branch and only picking bug > > fixes from master is the only guaranteed way to stabilize. Now you > > might say that there were only few unstable releases (AFAICT there was > > 2.19.65 before branching stable/2.20). However, I think there are > > already quite some user-facing changes and also the switch to Python 3. > > With Python 2.x being EOL since January, it's only a matter of time > > until Linux distributions and BSDs want to drop that, and it would be > > unfortunate if that put a (temporary) end to providing LilyPond for > > their users. If we had release candidates or even a stable version > > until then, it would definitely help. > > Maybe we could try to release 2.20.1 with Python 3? That would mean porting 50+ commits which sounds like a bad idea and even gets worse because of the reformatting in master. The latter implies that any bug fix made in master will result in merge conflicts. Plus I don't understand the proposal if you're at the same time saying that the scripts are fragile. By that logic, why would we backport such extensive changes and claim they're stable? > > The same can of course happen with Guile, but that situation has been > > going on for years. Furthermore, it's at least possible to compile and > > use current master with Guile 2.x, even if slower. In my understanding, > > things are getting better but properly integrating byte compilation is > > still a good amount of work that nobody could give a deadline on. > > > > WDYT? > > [Han-Wen] I think that both Python 3 support and usable (if imperfect) GUILE > 2 support is a strong argument for releasing a new stable version soon. > > Why Guile 2? If it's still imperfect and slower, we don't want to make it the > default in the binaries at lilypond.org, do we? So how will the situation be > different from 2.20? Sorry, I must be missing something obvious here... I > don't understand you. At least in my book, it's not about changing the default but at least making it possible for distributions to compile with Guile 2.x instead of just throwing LilyPond out. > At any rate, Python 3 support is great, but the scripts are fragile at the > moment. This is clear from the tracker and the bug-lilypond list. Our Python > scripts still need fixes in the way we distribute them, plus encoding-related > issues (I'm planning on tackling the latter point in a short period at the > end of August, but who knows what that will reveal). Could you please point to concrete issues? The distribution of scripts hasn't changed, so it basically still works the same it did for years (decades?). > [Han-Wen] I've been working on the build system (obviously), with in the back > of my mind having a build that is no longer recursive, but that work could be > paused for a bit while we prepare for releasing a 2.22. Is there a list of > problems in the current master that have to be resolved? > > Problems are basically popping every week (e.g., info installation, > translation tools, etc.). You're fixing them every week, which is really > great, but before creating a release branch that is devoted to stability, I > think we need a couple months to see what new problems appear, don't we? > > We have unstable releases to publish new features and get testing. In my > opinion, stable releases should really focus on stability, there's no need to > rush because of Python 3 and Guile 2. I don't think we'll get testing from distributions until we declare a way to stabilize. > At least four areas are currently under flux: Python scripts, the build > system, Guile 2 support, and fonts (Owen's project), and I don't see that > master is coming any close to stability. I think we are better with focusing > on these areas as long as they still require substantial attention, so as to > get a stable and nice LilyPond 2.22 in a timely manner. You derecursify the > build, David completes his stack of rather extensive purportive changes, Owen > merges the GSoC branch, etc., and only then it'll be time to care about > LilyPond 2.22. And that's my point: If we just sit and wait, the next stable release might happen after all major distributions threw LilyPond out - simply because it cannot be built in a world of Python 3. > Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup: > > > I'd like to ask what it would take in principle to branch stable/2.22 > > > and what others think about this. > > I don't see that this is a good point of time. > > There has been an influx of badly tested changes to the build system and > > directory setup and the web pages that has to stabilise and result in a > >
