LilyPond 2.20 release process

2016-12-31 Thread David Kastrup

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

2016-12-31 Thread Phil Holmes
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

2016-12-31 Thread David Kastrup
"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?

2016-12-31 Thread Han-Wen Nienhuys
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)

2016-12-31 Thread david . nalesnik

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)

2016-12-31 Thread Urs Liska
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

2016-12-31 Thread Trevor Daniels

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)

2016-12-31 Thread nine . fierce . ballads

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