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

[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.  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.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".