PATCHES - Countdown to February 15
Here is the current countdown report. The next countdown will begin on February 15th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1838 NR: Link 'Clef styles' appendix to 'Clef' section - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1838 !1828 Use get_strict_grob_direction in Slur code - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1828 !1816 expand documentation of defineBarLine - David Zelinsky https://gitlab.com/lilypond/lilypond/-/merge_requests/1816 Countdown: !1841 Bump a number of requirements - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1841 Review: !1843 NR: Include snippet `adjusting-slur-positions-vertically.ly` - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1843 !1840 Indentation from MusicXML imports - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1840 New: No patches in New at this time. Waiting: !1810 Let \rhythm markup derive from current layout - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1810 Cheers, Colin
Re: RFC: stop doing "grand replace" updates to copyright years
On Mon, Feb 13, 2023 at 11:53 AM Jean Abou Samra wrote: > > Le lundi 13 février 2023 à 11:07 +0100, Han-Wen Nienhuys a écrit : > > Hi there, > > Every year, we go over the source code to update the copyright years > that are found in the source headers. I propose to stop this. > > We started doing this because of the GNU standards which say > > https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html > > but we aren't following the instructions: the instructions are to only > update the year if there were nontrivial changes to the file. > > I don't understand this since it says > > """ When you add the new year, it is not required to keep track of which > files have seen significant changes in the new year and which have not. It is > recommended and simpler to add the new year to all files in the package, and > be done with it for the rest of the year. """ > > which sounds like exactly the opposite. I read it again, and you are right. The instructions say to update each file even if the file itself wasn't changed in that year. I guess the instructions codify what I find annoying in this practice: to touch files even if they weren't changed in any way. > If we stop doing grand-replace, does it mean we have to update the copyright > noticed manually when we change a file? No. > Git, for example, does not have an equivalent of grand-replace simply because > it does not have copyright notices in each file. > > If accepting this proposal just means no more grand-replace, I'm fine with > it, but it would seem a bit weird to keep "Copyright 1995-2023" at the top of > all files even in 2025. it is weird, but so is doing the grand update. We could decide to trim our license headers to a smaller SPDX identifier without a year, but we still have another year to go before a decision would make a difference. > To be honest, although I know there was work invested in them, I would > personally be glad to see the individual copyright notices in each file just > go away, although GNU purists will disagree. (But as a matter of fact, there > are a lot of dated recommendations in the technical side of the GNU > guidelines for maintainers.) -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: RFC: stop doing "grand replace" updates to copyright years
On Mon, 2023-02-13 at 13:36 +0100, Janneke Nieuwenhuizen wrote: > Han-Wen Nienhuys writes: > > Hey, > > > Every year, we go over the source code to update the copyright years > > that are found in the source headers. I propose to stop this. > > +1 > > > Also note that many other projects (eg. git) seem to survive just fine > > without yearly exercise like this. > > Yes. Of course, git is not a GNU project but I see this in projects > like Guix too. usually, $author includes a copyright year update in > their patch when they make a change to a file. For trivial changes, it > could be skipped but that's often usually up to the courtesy of $author. This is the approach I like the least of the three options, the others being the status quo and updating all files (as recommended by GNU, see Jean's reply) or to not have any years at all (like for example curl does: https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/). Updating years together with actual changes just calls for conflicts when two merge requests update the same file, or even worse when picking a fix to the stable branch. I'm against that if the "solution" is to just keep doing what we have in place right now. Han-Wen, could you please clarify which option you are proposing exactly? Side comment: IANAL, but my understanding is that copyright notices are notoriously wrong (at least for LilyPond) because every author retains their copyright. For that, it is simply irrelevant what a comment at the top of the file says, or even factually wrong if it only lists one (primary) author. Jonas signature.asc Description: This is a digitally signed message part
Re: [gnu-soc] GNU GSOC 2023 application
Hi Werner. > Hello Jose, > > > below is something for GNU LilyPond. I just updated the ideas page. Thanks! > > > Werner > > > == > > > LilyPond is a music engraving program, devoted to producing the > highest-quality sheet music possible. It brings the aesthetics of > traditionally engraved music to computer printouts. LilyPond is free > software and part of the GNU Project. > > Project site: https://lilypond.org/ > > > Adding variants of font glyphs > -- > > * Adding 'on' and 'between' staff-line variants. > > * Shorter and narrower variants of some glyphs (for example, > accidentals). Another, more specific example could be an ancient > notation breve notehead coming in two variants, one with a small and > one with a big 'hole' within it. > > Difficulty: easy/medium > Size: 175h/350h > Required skills: MetaFont, C++, good eye for details > Contact: 'lilypond-devel@gnu.org' mailing list > (https://lists.gnu.org/mailman/listinfo/lilypond-devel) > Recommended knowledge: basic LilyPond knowledge > > More GSoC ideas: https://lilypond.org/google-summer-of-code.html
Re: RFC: stop doing "grand replace" updates to copyright years
Han-Wen Nienhuys writes: Hey, > Every year, we go over the source code to update the copyright years > that are found in the source headers. I propose to stop this. +1 > Also note that many other projects (eg. git) seem to survive just fine > without yearly exercise like this. Yes. Of course, git is not a GNU project but I see this in projects like Guix too. usually, $author includes a copyright year update in their patch when they make a change to a file. For trivial changes, it could be skipped but that's often usually up to the courtesy of $author. Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: RFC: stop doing "grand replace" updates to copyright years
Le lundi 13 février 2023 à 11:07 +0100, Han-Wen Nienhuys a écrit : > Hi there, > > Every year, we go over the source code to update the copyright years > that are found in the source headers. I propose to stop this. > > We started doing this because of the GNU standards which say > > [https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html](https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html) > > but we aren't following the instructions: the instructions are to only > update the year if there were nontrivial changes to the file. I don't understand this since it says """ When you add the new year, it is not required to keep track of which files have seen significant changes in the new year and which have not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year. """ which sounds like exactly the opposite. > IIUC, this could make some difference in 95 years (?) from now when versions > of the file might enter the public domain (assuming humans still exist > as a species, and has a need for beautifully typeset music). > > I believe this advantage does not weigh up against the disadvantages, > which is that it makes the output of git-log harder to read, and that > the process takes up time and effort that could be more productively > spent elsewhere. > > Also note that many other projects (eg. git) seem to survive just fine > without yearly exercise like this. Also, at $dayjob, there are no > instructions to do this, despite open source work being carefully > overseen by lawyers. If we stop doing grand-replace, does it mean we have to update the copyright noticed manually when we change a file? Git, for example, does not have an equivalent of grand-replace simply because it does not have copyright notices in each file. If accepting this proposal just means no more grand-replace, I'm fine with it, but it would seem a bit weird to keep "Copyright 1995-2023" at the top of all files even in 2025. If it means updating those years manually while making changes, I prefer the yearly update to be done with it. To be honest, although I know there was work invested in them, I would personally be glad to see the individual copyright notices in each file just go away, although GNU purists will disagree. (But as a matter of fact, there are a lot of dated recommendations in the technical side of the GNU guidelines for maintainers.) signature.asc Description: This is a digitally signed message part
RFC: stop doing "grand replace" updates to copyright years
Hi there, Every year, we go over the source code to update the copyright years that are found in the source headers. I propose to stop this. We started doing this because of the GNU standards which say https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html but we aren't following the instructions: the instructions are to only update the year if there were nontrivial changes to the file. IIUC, this could make some difference in 95 years (?) from now when versions of the file might enter the public domain (assuming humans still exist as a species, and has a need for beautifully typeset music). I believe this advantage does not weigh up against the disadvantages, which is that it makes the output of git-log harder to read, and that the process takes up time and effort that could be more productively spent elsewhere. Also note that many other projects (eg. git) seem to survive just fine without yearly exercise like this. Also, at $dayjob, there are no instructions to do this, despite open source work being carefully overseen by lawyers. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
