This also makes a lot of sense to me, yes. L
On Mon, 23 May 2022, 13:12 Jean Abou Samra, <j...@abou-samra.fr> wrote: > > > Le 22/05/2022 à 21:52, Luca Fascione a écrit : > > > > On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > > > On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote: > > > So at the cost of rocking the cage a bit hard, I came asking the > > > uncomfortable question: > > > what would happen if (for this unique circumstance) we'd do what > one > > > would normally consider poor practice? > > > > Let's call your proposal by its true, scary name: we would > essentially > > *fork* Guile and, in the longer term, make it fit exactly what we > need > > for LilyPond. > > > > > > Well, I was not thinking the delta between "true" Guile and "ours" > > would ever get big. > > If it did, that is what I'd call a fork. And no, I'm _not_ advocating > > that. > > > > I'm more thinking something along the lines of make 3.81, actually: > > largely "mainline", > > plus a few small patches to adjust little details. (*) > > > > It's clear that a real fork is not useful here, I agree with you > > completely > > (*) 3.81 is famously incompatible with 3.82, and many large make > > systems are stuck in .81 land. > > So it's common for folks in that condition to build their own make > > applying a few (3? maybe 4) small > > patches to fix a few problems with the program instead. Effectively > > they run some kind of 3.81+ > > > > The second implication is that we get technologically stuck. > > > > > > Well, the idea is that much like now you'd state a dependency against > > Guile 2.2.x, > > you would then just ship the version you want. I don't see much of a > > difference there. > > (Again, the key in mind is that the changes from us are a _small_ set, > > so the fact that > > we would on occasion change the base checkout and reapply the diffs > > should be a > > small overhead. If you compound this with changed built to maximize > > the chances of > > eventual adoption, you'd risk eventually getting into a place where > > these changes are zero) > > > > With all that said, I think there are good reasons why things are > > considered bad practice. > > > > > > There were what felt like good reasons at the time when the practices > > were established, yes. > > > > However, as the hypotheses mutate, it can come a point where the > > conclusions don't follow any longer. > > > > For example: > > one doesn't want to fork because > > - it duplicates code and it's difficult to keep up the two diverged > > branches > > -> with RCS _definitely_, with git I'm not so sure. Space cost of > > duplication these days is zero. Time taken compiling one more repo, > > also zero. > > -> this means that now this part of the reason is reduced to > > understanding whether the divergence is large or small > > > > I've seen things that were bad practice when I was a student become > > acceptable or recommended now. > > I've come to see that "old wisdom" is sometimes not that wise after > > all (premature optimization for example, > > although in that case that's more an issue of misunderstanding of the > > original meaning, than actual change). > > > > Similar discussions have already taken place > > before, and I'm not sure if we're adding value by repeating them. > > Maybe > > we can come back to the original topic of this thread? > > > > > > Forgive me for making poor use of your and the others' time. > > I thought this might turn out to be pertinent if it opened up new ways > > of thinking about this choice. > > > > I might have introduced confusion with the mention of the bug > with source locations. In the specific case of LilyPond, this > bug is not very important. Almost all the warnings Guile gives > are pure noise in our case anyway (I haven't taken the time to > prepare an MR for silencing them yet). It was to illustrate the > fact that there can be serious bugs in Guile, and one could > well affect us. > > Apart from that, including the Guile sources in our tree and > building with them is something I would only do in a desperate > situation, e.g. Guile introducing changes that are fundamentally > incompatible with LilyPond's use case. It will be a nuisance > not to be able to use a Guile from the system since Guile these > days is quite slow to build. (The C code compiles fast, > but there is a whole bootstrap sequence to generate Scheme > compilers from Scheme code, which takes a lot of time.) > It will require synchronization with upstream if that is > desired. Also, while upstream isn't really active, they > do keep it at least building which is already something. > Rather, if it becomes clear that Guile is stuck, it would be > more reasonable to create a fork of Guile separate from LilyPond, > put it in a repository somewhere, invite the folks from guile-devel > who'd appreciate commit access on Guile but don't have it to > hack on it, advertise it for distros, apply patches from > the tracker, and try to either get upstream to realize its > model is not working and change it, or to make that a new > Guile with a community around it that can survive for the > decades to come. If we get a need to fork Guile (I don't > see a pressing need at the moment now that we are on > Guile 2/3), let's not do it in isolation. > > Jean > >