PATCHES - Countdown for February 18th
Hello, Here is the current patch countdown list. The next countdown will be on February 20th. A list of all merge requests can be found here: A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !653 Scoped lookup of music properties - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/653 !651 NR: Index entries for grob direction prefixes - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/651 !648 Recognize empty bar lines by shape, not glyph name - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/648 !644 Update auxiliary scripts for `configure`. - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/644 !643 IR beautification - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/643 !622 Initialize session from a dedicated parser - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/622 Countdown: !654 Don't close volta bracket at bar ".|:" or ".|" - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/654 !652 Avoid transparent bar lines in ancient staves - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/652 !649 Draft: Staff_spacing: recognize empty bar lines by width - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/649 Review: !655 Do not store Grob_info in engravers - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/655 New: No patches in New at this time. Waiting: No patches in Waiting at this time. *** Regards, James
Re: running `make grand-replace`
> To be clear, I do *not* plan to run grand-replace.py on the stable > branch. Instead I'll "just" update the few user-facing strings, in > lily/main.cc:273 and scripts/*. OK. I misunderstood. Werner
Re: running `make grand-replace`
Am Donnerstag, dem 18.02.2021 um 17:41 +0100 schrieb Werner LEMBERG: > > > We should run `make grand-replace` to update all copyright years. > > > Since this is a completely mechanical thing to do, I suggest to > > > submit the MR, wait until a build was successful, then > > > immediately > > > merging and committing it, bypassing the normal reviewing cycle. > > > This should minimize the hassles with additional rebasing of > > > future > > > MRs. > > > > > > Objections? > > > > Sounds good. > > OK, done. > > > On a related note, I think I'll also bump the years of user-visible > > messages in stable/2.22 to say 2021 instead of 2020. I forgot this > > for 2.22.0, but we can have it for a potential bugfix release. > > Does this make sense? > > Yes, it does. However, the `grand-replace.py` script updates *all* > occurrences of copyright strings, contrary to the gnulib script > `update-copyright`, which only updates the first one. It is thus > possible that this problem is gone. I don't get what you're saying here, sorry. To be clear, I do *not* plan to run grand-replace.py on the stable branch. Instead I'll "just" update the few user-facing strings, in lily/main.cc:273 and scripts/*. > Of course, the translation teams should now handle the `.po` files in > due course to complete the copyright issue update. The only translatable string with years is in scripts/musicxml2ly.py, and I think we should change that similar to all other instances that have a %s placeholder in the translatable string. Jonas > > Werner signature.asc Description: This is a digitally signed message part
Re: running `make grand-replace`
>> We should run `make grand-replace` to update all copyright years. >> Since this is a completely mechanical thing to do, I suggest to >> submit the MR, wait until a build was successful, then immediately >> merging and committing it, bypassing the normal reviewing cycle. >> This should minimize the hassles with additional rebasing of future >> MRs. >> >> Objections? > > Sounds good. OK, done. > On a related note, I think I'll also bump the years of user-visible > messages in stable/2.22 to say 2021 instead of 2020. I forgot this > for 2.22.0, but we can have it for a potential bugfix release. Does > this make sense? Yes, it does. However, the `grand-replace.py` script updates *all* occurrences of copyright strings, contrary to the gnulib script `update-copyright`, which only updates the first one. It is thus possible that this problem is gone. Of course, the translation teams should now handle the `.po` files in due course to complete the copyright issue update. Werner
