Werner LEMBERG <w...@gnu.org> writes: >> I don't see this hack as the canonical way to go forward, > > Interesting. I'm all ears to any more sensible solution which extends > the texinfo.tex framework without completely rewriting the font > selection mechanism. > >> and it is certainly not of the "obviously trivial and correct" >> quality warranting bypassing the review process for an invasive >> change with global consequences. > > OK. BTW, I got overwhelmingly reactions after posting the code to > lilypond-devel...
Oh come on. I quote the message: Simply include the attached file somewhere at the beginning of a document to have Cyrillic support (however, due to the used extension mechanism, you don't get kerning or hyphenation, even if you set the document language to Russian). Note that TeXLive doesn't come with precomposed TFM files for LH fonts; the first time you create a document, you will see a lot of additional activity. Another issue is that the index entries for sorting are bogus (in macro \cyrindexnofonts). Currently, this isn't of any importance because we don't have Cyrillic stuff in our indexes. Assuming that Cyrillic should be sorted after Latin, all entries start with ZZZZ, followed by `something' simply derived from the Cyrillic glyph's macro name. Maybe a native speaker can fix the `something', just in case. Enjoy! How is _anybody_ going to understand "Simply include ... at the beginning of a document... Enjoy!" as "Everybody attention! This is a formal request to include the following in our code base unconditionally. If nobody replies to this mail, I am going to push a globally active change along those lines to staging without further warning." This was not even phrased as a request for feedback or mentioning the idea of committing this to git. Yes, the master branch now has moved to 2.17. No, I don't have dictatorial power over anything but the 2.16 branch. No, our rules for committing to master have not suddenly ceased existing. No, 2.16.0 has not been released yet, and there is a reason for that. I don't have more than the power of appeal to ask people from refraining sabotaging the development branch until the settling phase of 2.16 is mostly over, and that will be the case when 2.16.0 and 2.17.0 have been released: everything that "actually should" be in 2.16.0 but did not warrant _further_ delaying 2.16.0 will end up in 2.17.0. If we put wild changes in 2.17.0 already, this will significantly delay 2.16.1 with followup changes (or testing exposure of its tentative contents) and will consequently affect the perceived quality of 2.16. It is not even two weeks, people. Get a grip. People are hard at work for getting a stable release out to the community. I will be fine with master getting large changes right after 2.17.0, preferably already cooked up and tested at that point of time. I can't expect to clamp down development for a longer amount of time. But give me a chance to bring off a reasonable 2.16 release. I need some cooperation for that. The job will realistically be mostly done with 2.16.1 rather than 2.16.0, exactly because of the reasons it has taken a year after the first release candidate to get it done: you can't expect to cut out a stable release in midflight development. And the pipelines will be blocked until 2.17.0 if 2.16.1 is going to make sense. Yes, I did not have the intelligence to demand this in advance. Guess what, this is my first time on a job of this size. So please keep the horses reined in until the new race can conscionably start for real. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel