Am Sonntag, den 08.03.2020, 12:34 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Sonntag, den 08.03.2020, 11:54 +0100 schrieb David Kastrup: > > > Han-Wen Nienhuys < > > > hanw...@gmail.com > > > > > > > writes: > > > > > What about "an error would be a nuisance when trying to have a common > > > > > configuration for both 2.20 and 2.21" was unclear? > > > > There will never be a shared configuration for both 2.20 and 2.21: > > Current master requires Python 3 which 2.20 not even attempts to be > > compatible with. > > Many systems install both Python2 and Python3 and the respective > configure scripts are perfectly fine finding and using the required > version. I wasn't trying to imply that we can share the _results_ of > running configure, but a common starting position, given the autoprobing > nature of autoconf, is a lot more realistic.
My point is that setting the PYTHON variable is equally broken. > > > This would concern things like running Patchy, and also things like > > > checking out pretests of stable releases for system packages. If the > > > spec files of the stable release fails mysteriously, most users will > > > give up. > > > > With the patch it doesn't fail "mysteriously" - there's a clear error > > saying what the tester is supposed to do. And from my understanding > > "unstable" releases really means that. > > Prereleases aren't as unstable. > > > > I cannot believe the resistance against creating a few dozen lines > > > for making the life for users and testers of LilyPond easier and > > > insisting on a configuration that will fail for everything except a > > > single painstakingly "correct" use that is not documented. > > > > As I wrote yesterday, the whole thing wasn't documented before. > > That's not something to be proud of. It means that things tended to > work by heresay and recipes passed around that took some pain to figure > out. It's not a state to aim for. > > > I politely ask to take a step back and try to understand the point of > > view shared by Werner, Han-Wen and me. > > That basically amounts to "we can figure it out, so everybody else > should". I don't doubt your competency, but it just isn't > representative for everyone wanting to use/compile/support LilyPond. No, it amounts to "it works the same as it does for other packages". > It isn't, for example, representative for the people typically doing git > bisection in order to find out where something went wrong. Hard cutoff > points in working configurations make something like bisection a lot > more painful. Not being able to change gradually makes development more painful. There was discussion as to why there are so few developers - this will be my prime reason if I'm required to add compatibility for everything. Yes, this includes things so fundamental as Guile.
signature.asc
Description: This is a digitally signed message part
