Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

[Jonas Hahnfeld]

Am Samstag, den 07.03.2020, 16:24 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup:
> > > Jonas Hahnfeld <
> > > address@hidden
> > > 
> > > > writes:
> > > > Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup:
> > > > > We are not talking about "keep everything compatible".  We are talking
> > > > > about making changes in a manner where they don't trip people up.  
> > > > > They
> > > > > way to deprecate a way of doing things is not to _start_ by pretending
> > > > > it never existed and silently ignore attempts to use it.  At the same
> > > > > time, by the way, not adapting any bit of documentation.
> > > > 
> > > > Acknowledged.
> > > > 
> > > > > For better or worse, deprecation takes work.  That's why we have, for
> > > > > example, convert-ly.  That's a user-level feature, but basically
> > > > > asserting that people able to compile LilyPond have to be able to deal
> > > > > with anything we throw at them without comment is not going to go down
> > > > > well with regard of keeping LilyPond supported by, say, major 
> > > > > GNU/Linux
> > > > > distributions.
> > > > 
> > > > Do expect "major GNU/Linux distributions" to package unstable
> > > > releases? I hope we don't force them by taking another 6 years for
> > > > 2.22
> > > 
> > > You make a good argument for keeping the deprecation warnings and code
> > > in for at least 2.22 so that major GNU/Linux distributions will be able
> > > to follow along.
> > > 
> > > The usual deprecation path for stuff like this is:
> > > 
> > > 1 stable release with continued support but warning containing all
> > >     necessary migration information -> 2.22
> > >     
> > > 1 stable release with discontinued support but error containing all
> > >     necessary migration information -> 2.24
> > > 
> > > 1 stable release with active support removed but transition explained in
> > > documentation -> 2.26
> > > 
> > > no mention anymore in code base -> 2.28
> > 
> > Are you serious about this for _any_ build system improvement that
> > changes a little how you compile LilyPond? I'm not talking about user-
> > facing stuff like notation syntax here, I would probably agree in that
> > context (via convert-ly).
> 
> Guile is not just "any" part of the build system.  And we are talking
> about investing an hour of work for us and milliseconds for the build
> system that saves system integrators 3 hours _each_ of work figuring out
> what went wrong.

My hope is that the integrators will switch to Guile 2.x anyhow once we
reach a stable release. That's surely more work and likely a good time
to cut old configuration variables.

> At some point of time you have to ask yourself why the
> time (let alone the goodwill) of downstream integrators is such garbage
> that wasting it for no significant gain is a good proposition.
> 
> > If your answer is yes, does this mean any change we do for 2.22 must
> > fully preserve build system compatibility? ie the all command lines
> > that work for 2.20 _must_ work for any 2.21.x and 2.22?
> 
> Please don't play the strawman game.  Not every problem is created
> equal, not every solution is the same.
> 
> Changing crucially important things in undocumented ways with silent
> failure to do the expected thing is not going to make us friends.  It
> would be a tough task to get people to consider me friendly.  But making
> LilyPond friendly is a different thing.
> 
> I don't see the point in "figure it out or die" changes.  It's just not
> a winning proposition.

Okay, so this doesn't lead to much progress from this point.
Would you be able to propose how the compatibility code for the
GUILE_CONFIG variable could look like? As far as I can see that's maybe
the only thing blocking a release (?).

Jonas

signature.asc
Description: This is a digitally signed message part