LilyPond 2.20 release process
In order to properly wrap up my maintainership of LilyPond, I would like to make sure that LilyPond 2.20 is released in an orderly manner. Work that does not appear to make sense to include in 2.20.1: a) Guile 2.0 support in release-quality manner and enabled by default. However, in order to incentivize further participation of volunteers, I would like to urge the people having recently worked on Guile 2.0 support to merge their work into the main line, if necessary guarded by suitable #ifdef (in C++) and the corresponding guards (in Scheme). b) default directory structures for enabling custom additions and work processes along the lines of openlilylib. I would urge the openlilylib crew to assess their current work and see whether they consider any parts suitably stable and robust and useful to include in the next release. c) thorough reorganizations of code, like trying to do rationals inside of Guile rather than separately. I may try something along that line eventually but there is no time line for it. What is definitely desired, however, is all of the following: Check any added features (that the authors knew to have implemented but not suitably documented) and see that we have regtests for them and reasonably good documentation. Have stable font support that works reliably on all platforms which we intend to support natively or with binaries. Figure out a strategy how to deal with distributions dropping support of Guile-1.8. It may be necessary to contact appropriate maintainers and previous contributors, and it may even be necessary to fork and maintain Guile-1.8 for an indefinite time as long as Guile-2.x+ cannot be turned into a satisfactory extension system due to disinterest of the Guile maintainers and/or the shortcomings in areas making it work as an extension language in the first place and/or lack of rearchitecting LilyPond where Guile's focus no longer matches the technical requirements of us. By far the least work (while Guile-2.x is not a reasonable option) would seem to be in the area of supporting a continued smooth inclusion of Guile-1.8 in distributions for a while. This is something that Guile developers do not like: it might be used as an incentive to actually get any of them to look at the problems LilyPond provides. Naturally, if one can smoothly compile LilyPond for both Guile-1.8 and Guile-2.0 (requiring readily available development environments for both, again making it desirable for distributions to continue including them for a while), the comparison of their performance and issues will be reproducible for anyone with an interest. We _really_ want this kind of showroom in order to advertise the current problems and make Guile developers care. So I really would urge the Guile-2 warriors to fold their work into the mainline. We want it distributed by default, but probably with a stronger warning against --enable-guilev2 (or what it was called), bluntly mentioning the speed of LilyPond dropping to a third. --- So the usual proposition would be a feature freeze first to give people time to focus exclusively on release-readiness. After the main flurry of release-level commits has abated mostly, the release branch will be forked. Development work can then pick up again on the master branch. Documentation changes relevant for the release branch may get picked into the release branch, so major documentation reorganizations and other disruptive changes or refactorings making it hard to cherry-pick bug fixes and last minute documentation changes from master into the release branch should be done in developer branches instead. At any rate, translators should focus on translating the release branch at this point of time. Bug fixes and documentation fixes occuring in master will be cherry-picked into the release branch as appropriate in a continuing way. Before release is imminent, all translations should at least try to update the Changes files, and we would want a boilerplate text to include in the main documentation web links to point people to the current original (or uptodate translations) for all translations that have not kept up. It might also be appropriate to include a warning in every translation that states the approximate documented version if it isn't the current one. >From the time of the release branch fork to the actual release (approximately 1 month), it may make sense to refrain from releasing any developer release in order not to confuse the versioning and to keep people focused on the release. That's not an iron rule but it makes some sense, and in order to avoid double work for the release managers, we might be putting out prereleases only instead of developer releases. That's the rough sketch of how things mostly worked out in the past, and how I see this taking place this time (anyone want to preserve this text or a summary of its structure without the stuff pertinent only to this release for the Contributors' Guide? Seems
Re: LilyPond 2.20 release process
I think there are a few bugs that need attention prior to stable release. https://sourceforge.net/p/testlilyissues/issues/4975/ is one I'm aware of, and there are a number of ones marked as critical. -- Phil Holmes - Original Message - From: "David Kastrup" To: Sent: Saturday, December 31, 2016 9:31 AM Subject: LilyPond 2.20 release process In order to properly wrap up my maintainership of LilyPond, I would like to make sure that LilyPond 2.20 is released in an orderly manner. Work that does not appear to make sense to include in 2.20.1: a) Guile 2.0 support in release-quality manner and enabled by default. However, in order to incentivize further participation of volunteers, I would like to urge the people having recently worked on Guile 2.0 support to merge their work into the main line, if necessary guarded by suitable #ifdef (in C++) and the corresponding guards (in Scheme). b) default directory structures for enabling custom additions and work processes along the lines of openlilylib. I would urge the openlilylib crew to assess their current work and see whether they consider any parts suitably stable and robust and useful to include in the next release. c) thorough reorganizations of code, like trying to do rationals inside of Guile rather than separately. I may try something along that line eventually but there is no time line for it. What is definitely desired, however, is all of the following: Check any added features (that the authors knew to have implemented but not suitably documented) and see that we have regtests for them and reasonably good documentation. Have stable font support that works reliably on all platforms which we intend to support natively or with binaries. Figure out a strategy how to deal with distributions dropping support of Guile-1.8. It may be necessary to contact appropriate maintainers and previous contributors, and it may even be necessary to fork and maintain Guile-1.8 for an indefinite time as long as Guile-2.x+ cannot be turned into a satisfactory extension system due to disinterest of the Guile maintainers and/or the shortcomings in areas making it work as an extension language in the first place and/or lack of rearchitecting LilyPond where Guile's focus no longer matches the technical requirements of us. By far the least work (while Guile-2.x is not a reasonable option) would seem to be in the area of supporting a continued smooth inclusion of Guile-1.8 in distributions for a while. This is something that Guile developers do not like: it might be used as an incentive to actually get any of them to look at the problems LilyPond provides. Naturally, if one can smoothly compile LilyPond for both Guile-1.8 and Guile-2.0 (requiring readily available development environments for both, again making it desirable for distributions to continue including them for a while), the comparison of their performance and issues will be reproducible for anyone with an interest. We _really_ want this kind of showroom in order to advertise the current problems and make Guile developers care. So I really would urge the Guile-2 warriors to fold their work into the mainline. We want it distributed by default, but probably with a stronger warning against --enable-guilev2 (or what it was called), bluntly mentioning the speed of LilyPond dropping to a third. --- So the usual proposition would be a feature freeze first to give people time to focus exclusively on release-readiness. After the main flurry of release-level commits has abated mostly, the release branch will be forked. Development work can then pick up again on the master branch. Documentation changes relevant for the release branch may get picked into the release branch, so major documentation reorganizations and other disruptive changes or refactorings making it hard to cherry-pick bug fixes and last minute documentation changes from master into the release branch should be done in developer branches instead. At any rate, translators should focus on translating the release branch at this point of time. Bug fixes and documentation fixes occuring in master will be cherry-picked into the release branch as appropriate in a continuing way. Before release is imminent, all translations should at least try to update the Changes files, and we would want a boilerplate text to include in the main documentation web links to point people to the current original (or uptodate translations) for all translations that have not kept up. It might also be appropriate to include a warning in every translation that states the approximate documented version if it isn't the current one. From the time of the release branch fork to the actual release (approximately 1 month), it may make sense to refrain from releasing any developer release in order not to confuse the versioning and to keep people focused on the release. That's not an iron rule but it makes some sense, and in order to avoid double
Re: LilyPond 2.20 release process
"Phil Holmes" writes: > I think there are a few bugs that need attention prior to stable > release. https://sourceforge.net/p/testlilyissues/issues/4975/ is one > I'm aware of, and there are a number of ones marked as critical. Sounds like something that might be addressed by a compiler update in Gub. Not the most satisfactory solution, but if it works, probably most expedient. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Free alternatives to Rietveld?
You could switch to Gerrit for code review. It is a native git tool, so it needs less awkward scripts. There are some hosted providers (such as gerrithub), or you can run your own version of Gerrit if you have inclination to set it up. Setting up your own account authentication infrastructure is pretty annoying, and running it yourself is unlikely to save you time. On Tue, Dec 27, 2016 at 1:33 PM, Simon Albrecht wrote: > Hello everybody, > > just now I tried to login with Google in order to close my two recent > Rietveld reviews. However, Google decided that despite entering a > verification code from e-mail it couldn’t confirm me being authorised to > login. So I’m currently out. Maybe they want to force me to give a mobile > phone number? > > Whatever the reason for this weirdness, I think it would really be better if > we had a code review tool which didn’t rely on external login providers. Is > there really no free alternative? > > Best, Simon > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allow fixed spacing of symbols in church rests (issue 319910043 by david.nales...@gmail.com)
Please see http://www.mail-archive.com/lilypond-user@gnu.org/msg117437.html https://codereview.appspot.com/319910043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
OLL features (was: LilyPond 2.20 release process)
Hi all, Am 31.12.2016 um 10:31 schrieb David Kastrup: > I would urge the openlilylib > crew to assess their current work and see whether they consider any > parts suitably stable and robust and useful to include in the next > release. I see three items in openLilyLib that I would like to discuss in this context, before possibly investing any work, one small and two bigger ones. 1) I am very happy about the LilyPond version predicates that allow you to write code that supports multiple LilyPond versions. This is a complementary use case to convert-ly for cases (libraries or frameworks) that are intended to support e.g. stable and devel versions. Through calls to (if (lilypond-greater-than? '(2 19 21)) (and the sibling procedures) alternative code can be evaluated depending on the currently run LilyPond version. openLilyLib makes quite some use of this, particularly around the "parser" thing. I'd like to create a patch for this if there's no objection already at this stage. 2) "Option handling" A fundamental feature of openLilyLib is what I called "option handling" but which is actually somewhat more, kind of data handling (don't know what a proper name should be). It is a Scheme tree object that can hold arbitrary data (originally: options) that can be accessed through - \registerOption - \setOption - \getOption[WithFallback] - \[get|set]ChildOption There are two main points to using/having it: a) there's only one distinct name around, so you don't have to "pollute" the namespace with variables. b) it is very easy to use and it has proven invaluable to me for creating infrastructures - as it gives a quite high level access to something that would otherwise be quite painful and therefore comparably unused. The original idea was to establish options with default values (a library would e.g. initialize with \registerOption scholarly.annotate.use-color ##t ), while the user could configure the actual behaviour with \setOption scholarly.annotate.use-color ##f Library functions would then implement switches according to option values. In the meantime I have realized that the "options" can be used to store arbitrary data, for example parsed music expressions. In a project I parse the parts and store them in "options", and when I then create individual parts and the score they can be reused without having to be re-parsed. So I think this functionality would be a very useful enhancement to the programming toolkit for LilyPond. Regarding the implementation in LilyPond itself I can't say how much work it will be to pull it out of openLilyLib and re-implement in vanilla Lilypond. Probably this would be an independent Scheme module (where one had to discuss if it's loaded automatically or only provided to be used). Additionally this would add quite a number of useful lower-level functions (by Jan-Peter) that simplify the use of association lists in general. 3) As it has just been discussed I'd like to ask if we should make an effort incorporating the \shapeII improvements into \shape. One problem I see here is that this probably wouldn't simply be about including existing code in LilyPond. I have the impression we would have to look at \shapeII (as per openLilyLib) and reimplement it on top of \shape, partially because there is now much better support for the complex geometric calculations Janek did "by hand" then. I have the impression this might be too long a shot to get into a stable release by February. Bot OTOH it would be so much worth the effort to have in a 2.20, considering that a 2.22 is presumably quite some time away. What do you think? Best Urs -- Urs Liska https://openlilylib.org http://lilypondblog.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.20 release process
Phil Holmes wrote Saturday, December 31, 2016 11:03 AM >I think there are a few bugs that need attention prior to stable release. > https://sourceforge.net/p/testlilyissues/issues/4975/ is one I'm aware of, > and there are a number of ones marked as critical. There are four bugs marked as critical regressions, see: https://sourceforge.net/p/testlilyissues/issues/search/?q=%28_type%3ACritical+OR+labels%3ARegression%29+AND+%28status%3ANew+OR+status%3AAccepted+OR+status%3AStarted%29 It seems the sources of these bugs have been traced to patches submitted by devs who are no longer active: https://sourceforge.net/p/testlilyissues/issues/4807/ Keith O'Hara https://sourceforge.net/p/testlilyissues/issues/4751/ John Gourlay https://sourceforge.net/p/testlilyissues/issues/4182/ Janek Warchol https://sourceforge.net/p/testlilyissues/issues/3778/ Mike Solomon The patches are all large and quite far-reaching, so reversion is not an option. Debugging has been attempted and (so far) abandoned. So it is not clear what should be done. Discuss. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allow fixed spacing of symbols in church rests (issue 319910043 by david.nales...@gmail.com)
On 2016/12/31 17:22:56, david.nalesnik wrote: Please see http://www.mail-archive.com/lilypond-user@gnu.org/msg117437.html I believe I've done my part in raising the question about defaults. I'll leave the decision to the more informed. https://codereview.appspot.com/319910043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel