Re: Cyrillic texinfo support

[David Kastrup]

Werner LEMBERG <address@hidden> 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