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
Re: running `make grand-replace`
Am Mittwoch, dem 17.02.2021 um 08:25 +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. 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? Jonas signature.asc Description: This is a digitally signed message part
Re: running `make grand-replace`
Am 17.02.2021 um 14:11 schrieb Dan Eble: On Feb 17, 2021, at 02:25, Werner LEMBERG wrote: 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? no objection +1 — Dan
Re: running `make grand-replace`
On Feb 17, 2021, at 02:25, Werner LEMBERG wrote: > > 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? no objection — Dan
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? Werner
Make grand-replace
Hello, I noticed this command http://lilypond.org/doc/v2.15/Documentation/contributor/unsorted-policies :) So I tried it... Gosh... that command touches 'one or two' files doesn't it! chuckle Umm.. I guess this is something that a 'senior' dev probably should do as it also touches all the translated files too. Maybe on the next dev release? Regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make grand-replace
On Sun, Jan 08, 2012 at 09:53:16PM +, James wrote: http://lilypond.org/doc/v2.15/Documentation/contributor/unsorted-policies thanks, run. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
