Re: branching stable/2.22?
>> [...] if I delete a PDF file, say, `notation.pdf`, right now it >> gets *not* rebuilt! > > The new documentation build has much more accurate dependency > tracking, so if you want to rebuild notation.pdf, you can just say > so: > > make out=www out-www/en/notation.pdf Aah, I tried without `out=www`. This incantation is good enough for me, thanks. No further action needed. >> Similarly, if I change a documentation string in an SCM file like >> `define-markup-commands.scm`, the documentation doesn't get >> rebuilt, either. > > I can look at reintroducing the SCM -> texi dependencies. Please do so. Due to the auto-generation process, it is far from trivial to find out which command has to be called. >> I consider this fundamental flaws. > > I disagree. These flaws might be a bother for developers, but > branching stable/2.22 is about not having user-visible regressions > of lilypond itself, relative to 2.20, which has nothing to do with > how developers experience working on lilypond. OK. >> For me, a freeze can only start if we agree that nothing >> fundamental has to be changed or added. IMHO, we are far away from >> such a state. > > Could you enumerate the issues you think are fundamental? Well, I referred mainly to the build problems. Since your goal to cut stable/2.22 is a bit different my arguments are moot. Werner
Re: branching stable/2.22?
On Sep 11, 2020, at 15:19, James Lowe wrote: > > On 11/09/2020 20:13, Han-Wen Nienhuys wrote: >>> I consider this fundamental flaws. >> I disagree. These flaws might be a bother for developers, but >> branching stable/2.22 is about not having user-visible regressions of >> lilypond itself, relative to 2.20, which has nothing to do with how >> developers experience working on lilypond. >> > I'm with Han-Wen on this. > > PDF building has nothing whatsoever to do with what most users need. This is > the 'build' stuff that frankly can wait until we have fixed the > regressions/documentation of features. I lean toward letting the people who want to freeze/stabilize/release get on with it. I would hold back my \volta changes for the month or so that it takes to do this, work on related new features on my own, and contribute bug fixes as I find them. — Dan
Re: branching stable/2.22?
On 11/09/2020 20:13, Han-Wen Nienhuys wrote: I consider this fundamental flaws. I disagree. These flaws might be a bother for developers, but branching stable/2.22 is about not having user-visible regressions of lilypond itself, relative to 2.20, which has nothing to do with how developers experience working on lilypond. I'm with Han-Wen on this. PDF building has nothing whatsoever to do with what most users need. This is the 'build' stuff that frankly can wait until we have fixed the regressions/documentation of features. James
Re: branching stable/2.22?
On Fri, Sep 11, 2020 at 7:08 PM Werner LEMBERG wrote: > > > >> > I don't see that in the current stage of upheaval of both > >> > internals and build system and infrastructure, there is a point > >> > in freezing off some half-baked intermediate state that hasn't > >> > seen significant exposure to extensive testing. > >> > >> +1 It's too early IMHO. Let's wait at laest a month. > > > > To be clear here: You mean at least one month before starting a > > freeze? > > Yes. The build infrastructure is still not ok. For example, if I > delete a PDF file, say, `notation.pdf`, right now it gets *not* > rebuilt! There is a comment about this: # Do not specify phony targets (pdf, html) as dependencies to avoid building the # webdoc tree every time. We can make this accurate so your pdf file gets rebuilt, but it comes at the cost of always building the webdoc tree even if there is no work to do. This adds 5 to 10 seconds to a null-build, so I think it's not a good tradeoff. The new documentation build has much more accurate dependency tracking, so if you want to rebuild notation.pdf, you can just say so: make out=www out-www/en/notation.pdf > Similarly, if I change a documentation string in an SCM file > like `define-markup-commands.scm`, the documentation doesn't get > rebuilt, either. I can look at reintroducing the SCM -> texi dependencies. > I consider this fundamental flaws. I disagree. These flaws might be a bother for developers, but branching stable/2.22 is about not having user-visible regressions of lilypond itself, relative to 2.20, which has nothing to do with how developers experience working on lilypond. > > This is not my proposal anymore to just branch, but Han-Wen's idea of > > having a freeze of 3-4 weeks before branching. > > For me, a freeze can only start if we agree that nothing fundamental > has to be changed or added. IMHO, we are far away from such a state. Could you enumerate the issues you think are fundamental? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: branching stable/2.22?
>> This is not my proposal anymore to just branch, but Han-Wen's idea >> of having a freeze of 3-4 weeks before branching. > > For me, a freeze can only start if we agree that nothing fundamental > has to be changed or added. IMHO, we are far away from such a > state. What we can start, however, is a feature freeze, especially syntax-wise. So if you mean exactly that, I support that idea. Werner
Re: branching stable/2.22?
>> > I don't see that in the current stage of upheaval of both >> > internals and build system and infrastructure, there is a point >> > in freezing off some half-baked intermediate state that hasn't >> > seen significant exposure to extensive testing. >> >> +1 It's too early IMHO. Let's wait at laest a month. > > To be clear here: You mean at least one month before starting a > freeze? Yes. The build infrastructure is still not ok. For example, if I delete a PDF file, say, `notation.pdf`, right now it gets *not* rebuilt! Similarly, if I change a documentation string in an SCM file like `define-markup-commands.scm`, the documentation doesn't get rebuilt, either. I consider this fundamental flaws. > This is not my proposal anymore to just branch, but Han-Wen's idea of > having a freeze of 3-4 weeks before branching. For me, a freeze can only start if we agree that nothing fundamental has to be changed or added. IMHO, we are far away from such a state. Werner
Re: branching stable/2.22?
Am Freitag, den 11.09.2020, 16:18 +0100 schrieb James Lowe: > On 11/09/2020 15:22, David Kastrup wrote: > > Jonas Hahnfeld writes: > > > > > Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld: > > > > Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys: > > > > > Here is my proposal for how to go ahead: > > > > > > > > > > * we build a 2.21.6 from master, and announce it widely as a 2.22 > > > > > pre-release version. > > > > > > > > Adding Phil. I did a full test build of current master yesterday and it > > > > worked fine with https://github.com/gperciva/gub/pull/80 in place. > > > > With respect to wording, every 2.21.x is some kind of pre-release for > > > > 2.22. If this proposal gets consensus, I'd emphasize that feature > > > > development is over, but I'll leave that to native speakers > > > > > > > > > * we institute a X week freeze; during the freeze, we only merge > > > > >- fixes for regressions > > > > >- updates to the documentation > > > > >- cleanups with no functional changes, with little risk (ie. > > > > > refrain > > > > > from build system changes, for example). > > > > > * after the X week freeze, if we still have open regressions, we tack > > > > > on another few weeks of freeze to fix them. > > > > > * if there are no regressions left, we branch stable/2.22, and release > > > > > a new pre-release. > > > > > > > > > > X could be up for discussion, but 3 or 4 weeks seems long enough to > > > > > gather some feedback, but short enough that experimental/feature work > > > > > should not be affected. > > > > > > > > > > The objective of the freeze is to focus developer energy on fixing > > > > > regressions rather than causing new regressions. > > > > > > > > Sounds good to me. > > > > > > To arrive at a decision, what do others think about this? Having a > > > large silent mass is not really helpful for this kind of discussion (as > > > it wasn't for the switch to GitLab). > > > > Frankly I don't see the point in repeating points I already made and > > call that "discussion". > > > > I don't see that in the current stage of upheaval of both internals and > > build system and infrastructure, there is a point in freezing off some > > half-baked intermediate state that hasn't seen significant exposure to > > extensive testing. > > > > I cannot comment on 'Internals' but 'build system' and 'infrastructure' > are not, I think, issues that really concern 'average Joe User' who > wants to download and install a version of LP that works. That doesn't > mean they don't matter but I don't see us getting all our proverbial > waterfowl in a row any time soon with all the mix of MRs I am seeing of > build/Infra and LP-specific. So we have to draw a line in the sand > somewhere if only for those developers that just want to do 'build > system and infrastructure' stuff so unless anything is broken 'now' for > the build, why not just stop accepting any more MRs for it at this time? > > In effect I agree with Jonas' plan To keep things together, it was Han-Wen's proposal that I just happened to quote. (My original question didn't have a freeze). > but slightly modified, I suggest that > unless anything is really broken with the build system 'today' (and I am > not getting that vibe from the conversations I read) we have one more > countdown for 'anything' build-related to get in the patch countdown and > after that, we only focus on Regressions and docs, anything currently in > the patch countdown that is build related gets counted down normally (if > it gets pulled/needs more changes it cannot come back in) and eventually > the countdown should only contain LP/Doc MRs and possibly even peter out > to nothing which would be a good indicator of when to revisit a 'when > shall we freeze'. > > I don't do any development so feel a bit brash saying all this but > personally I don't think we will need 'weeks' to decide a freeze date, I > think it might become very obvious, very quickly once we prohibit > build/infra MRs and focus on regressions/docs. And until someone 'says' > an actual date - and gets feed back on that - I think we may keep on > procrastinating. > > As for 'extensive testing' well all that I can see we can do here I > think is announce this to the user group and ask for help testing - even > just running 'a build' on some big and/or complex scores and ask for > feedback (perhaps put something on the website). I don't know what else > we can do for testing. Other than that, I fully agree with all you say (which was the reason I didn't have a freeze initially and would have just picked whatever necessary into the created branch, but that's off the table now). Basically everything that gives an actable plan with consensus is fine for me, I just want to avoid doing nothing until it's urgent. Jonas signature.asc Description: This is a digitally signed message part
Re: branching stable/2.22?
Am Freitag, den 11.09.2020, 17:14 +0200 schrieb Werner LEMBERG: > > I don't see that in the current stage of upheaval of both internals and > > build system and infrastructure, there is a point in freezing off some > > half-baked intermediate state that hasn't seen significant exposure to > > extensive testing. > > +1 It's too early IMHO. Let's wait at laest a month. To be clear here: You mean at least one month before starting a freeze? This is not my proposal anymore to just branch, but Han-Wen's idea of having a freeze of 3-4 weeks before branching. signature.asc Description: This is a digitally signed message part
Re: branching stable/2.22?
On 11/09/2020 15:22, David Kastrup wrote: Jonas Hahnfeld writes: Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld: Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys: Here is my proposal for how to go ahead: * we build a 2.21.6 from master, and announce it widely as a 2.22 pre-release version. Adding Phil. I did a full test build of current master yesterday and it worked fine with https://github.com/gperciva/gub/pull/80 in place. With respect to wording, every 2.21.x is some kind of pre-release for 2.22. If this proposal gets consensus, I'd emphasize that feature development is over, but I'll leave that to native speakers * we institute a X week freeze; during the freeze, we only merge - fixes for regressions - updates to the documentation - cleanups with no functional changes, with little risk (ie. refrain from build system changes, for example). * after the X week freeze, if we still have open regressions, we tack on another few weeks of freeze to fix them. * if there are no regressions left, we branch stable/2.22, and release a new pre-release. X could be up for discussion, but 3 or 4 weeks seems long enough to gather some feedback, but short enough that experimental/feature work should not be affected. The objective of the freeze is to focus developer energy on fixing regressions rather than causing new regressions. Sounds good to me. To arrive at a decision, what do others think about this? Having a large silent mass is not really helpful for this kind of discussion (as it wasn't for the switch to GitLab). Frankly I don't see the point in repeating points I already made and call that "discussion". I don't see that in the current stage of upheaval of both internals and build system and infrastructure, there is a point in freezing off some half-baked intermediate state that hasn't seen significant exposure to extensive testing. I cannot comment on 'Internals' but 'build system' and 'infrastructure' are not, I think, issues that really concern 'average Joe User' who wants to download and install a version of LP that works. That doesn't mean they don't matter but I don't see us getting all our proverbial waterfowl in a row any time soon with all the mix of MRs I am seeing of build/Infra and LP-specific. So we have to draw a line in the sand somewhere if only for those developers that just want to do 'build system and infrastructure' stuff so unless anything is broken 'now' for the build, why not just stop accepting any more MRs for it at this time? In effect I agree with Jonas' plan but slightly modified, I suggest that unless anything is really broken with the build system 'today' (and I am not getting that vibe from the conversations I read) we have one more countdown for 'anything' build-related to get in the patch countdown and after that, we only focus on Regressions and docs, anything currently in the patch countdown that is build related gets counted down normally (if it gets pulled/needs more changes it cannot come back in) and eventually the countdown should only contain LP/Doc MRs and possibly even peter out to nothing which would be a good indicator of when to revisit a 'when shall we freeze'. I don't do any development so feel a bit brash saying all this but personally I don't think we will need 'weeks' to decide a freeze date, I think it might become very obvious, very quickly once we prohibit build/infra MRs and focus on regressions/docs. And until someone 'says' an actual date - and gets feed back on that - I think we may keep on procrastinating. As for 'extensive testing' well all that I can see we can do here I think is announce this to the user group and ask for help testing - even just running 'a build' on some big and/or complex scores and ask for feedback (perhaps put something on the website). I don't know what else we can do for testing. Thanks for listening. James
Re: branching stable/2.22?
> I don't see that in the current stage of upheaval of both internals and > build system and infrastructure, there is a point in freezing off some > half-baked intermediate state that hasn't seen significant exposure to > extensive testing. +1 It's too early IMHO. Let's wait at laest a month. Werner
Re: branching stable/2.22?
Jonas Hahnfeld writes: > Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld: >> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys: >> > Here is my proposal for how to go ahead: >> > >> > * we build a 2.21.6 from master, and announce it widely as a 2.22 >> > pre-release version. >> >> Adding Phil. I did a full test build of current master yesterday and it >> worked fine with https://github.com/gperciva/gub/pull/80 in place. >> With respect to wording, every 2.21.x is some kind of pre-release for >> 2.22. If this proposal gets consensus, I'd emphasize that feature >> development is over, but I'll leave that to native speakers >> >> > * we institute a X week freeze; during the freeze, we only merge >> > - fixes for regressions >> > - updates to the documentation >> > - cleanups with no functional changes, with little risk (ie. refrain >> > from build system changes, for example). >> > * after the X week freeze, if we still have open regressions, we tack >> > on another few weeks of freeze to fix them. >> > * if there are no regressions left, we branch stable/2.22, and release >> > a new pre-release. >> > >> > X could be up for discussion, but 3 or 4 weeks seems long enough to >> > gather some feedback, but short enough that experimental/feature work >> > should not be affected. >> > >> > The objective of the freeze is to focus developer energy on fixing >> > regressions rather than causing new regressions. >> >> Sounds good to me. > > To arrive at a decision, what do others think about this? Having a > large silent mass is not really helpful for this kind of discussion (as > it wasn't for the switch to GitLab). Frankly I don't see the point in repeating points I already made and call that "discussion". I don't see that in the current stage of upheaval of both internals and build system and infrastructure, there is a point in freezing off some half-baked intermediate state that hasn't seen significant exposure to extensive testing. -- David Kastrup
Re: branching stable/2.22?
Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld: > Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys: > > Here is my proposal for how to go ahead: > > > > * we build a 2.21.6 from master, and announce it widely as a 2.22 > > pre-release version. > > Adding Phil. I did a full test build of current master yesterday and it > worked fine with https://github.com/gperciva/gub/pull/80 in place. > With respect to wording, every 2.21.x is some kind of pre-release for > 2.22. If this proposal gets consensus, I'd emphasize that feature > development is over, but I'll leave that to native speakers > > > * we institute a X week freeze; during the freeze, we only merge > > - fixes for regressions > > - updates to the documentation > > - cleanups with no functional changes, with little risk (ie. refrain > > from build system changes, for example). > > * after the X week freeze, if we still have open regressions, we tack > > on another few weeks of freeze to fix them. > > * if there are no regressions left, we branch stable/2.22, and release > > a new pre-release. > > > > X could be up for discussion, but 3 or 4 weeks seems long enough to > > gather some feedback, but short enough that experimental/feature work > > should not be affected. > > > > The objective of the freeze is to focus developer energy on fixing > > regressions rather than causing new regressions. > > Sounds good to me. To arrive at a decision, what do others think about this? Having a large silent mass is not really helpful for this kind of discussion (as it wasn't for the switch to GitLab). Jonas signature.asc Description: This is a digitally signed message part
Re: Lilypond build
Am Freitag, den 11.09.2020, 12:20 +0100 schrieb Phil Holmes: > I can't work out whether there was consensus on the next released build. With nobody else replying, I wouldn't call it consensus. > Are we going with 2.21.6 and a release announcement that this is an initial > pre-release for a new stable 2.22.0? Or perhaps go for 2.21.80 as a clearer > sign that it's a pre-release? IMHO the next release from master / unstable should be 2.21.6, with the bump only happening after branching stable/. In any case, please do not produce a build right now because https://gitlab.com/lilypond/lilypond/-/merge_requests/373 broke the inclusion of snippets into the Documentation build... Jonas signature.asc Description: This is a digitally signed message part
Lilypond build
I can't work out whether there was consensus on the next released build. Are we going with 2.21.6 and a release announcement that this is an initial pre-release for a new stable 2.22.0? Or perhaps go for 2.21.80 as a clearer sign that it's a pre-release? -- Phil Holmes
PATCHES - Countdown for September 11th
Hello, Here is the current patch countdown list. The next countdown will be on September 13th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !387 doc: remove timestamp from HTML output - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/387 !385 lily: tweak line_dimensions_int() - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/385 !384 doc: look for snippet titles/docs in output-dir rather than origdir - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/384 !383 lily: ignore non-spanners in Vertical_align_engraver - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/383 !382 lily: fix crash with stemlets on kneed beams - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/382 !381 Fix crash for pagebreak at score start; minor related cleanups. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/381 !380 Add README.md - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/380 Countdown: !389 Define default associatedVoiceType for performance - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/389 !388 Fixes and many cleanups to scripts/auxiliar - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/388 !386 Add \volta i,j,k command to mark volta-specific music - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/386 !370 lilypond-book: fix --filter option - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/370 Review: !391 LSR import - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/391 !390 Added quarter-sharp slash.stem glyph - David Stephen Grant https://gitlab.com/lilypond/lilypond/-/merge_requests/390 New: !392 lilypond-book: write documents after process_cmd finishes - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/392 Waiting: !344 WIP: fully qualify doc includes. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/344 !204 Move parallel processing to lilypond-book - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/204 *** Regards, James
Re: font problems
>> OK. Could you please send me the list of available fonts in the >> docker image? > > Get it with > $ docker run --rm -ti > registry.gitlab.com/lilypond/lilypond/ci/ubuntu-16.04:20200829 $cmd > > Attached is the full output of fc-list, Thanks a lot! I think that we can easily adjust the used fonts to that, with the exception of Japanese. Werner
