Re: Cyrillic texinfo support

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>> 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.
>
> Hmm, `wild changes' is a mild exaggeration, isn't it?  It makes
> 50 Cyrillic characters appear in the PDFs which were simply missing
> previously.  It's a one-line change in `macros.itexi'

In macros.itexi which is used throughout the entire documentation, for
every single Texinfo document, whether generating PDF, info, HTML.  Have
you checked the performance impact?  Have you checked that the info
documents still are fine after "make info"?

> and a new file.  And of course I've run `make doc' on a freshly cloned
> git repository and checked the output whether everything is fine.
>
> Anyway, I now understand that we essentially have a code freeze in
> `staging' until 2.16 is out.

No, it is not a code freeze.  And I don't have the power to demand that.
And it is not necessary either since 2.17.0 and 2.16 are in different
branches, and there is no intent of doing a merge between branches.
2.17.0 will not be the same as 2.16.1.  Any change with localized effect
can be put into master right now without affecting the value of 2.17.0
for test-driving post-2.16.0 changes in public.

So no, we don't have a code freeze.  Not even essentially.  We did not
have it in 2.15, and we don't have it in 2.17.  But we still have cause
for the same amount of restraint that was exercised in 2.15.  In my
opinion, it does not make sense to start the wild code bonanza until
2.17.0 is out.

And even when the wild code bonanza has started, we will have review
processes, and I, like every other developer, have the right to mention
my concerns in reviews when changes with large impact are made.  There
will always be small localized obvious changes where individual
developers might choose not to bother with a full review.

A change affecting the whole Documentation system is something different
in my opinion.  And when there likely is reasonable doubt about the
triviality of a change, a review is called for.

> Somehow I got a wrong impression about that, sorry.

It does not need a "code freeze" for our review procedures to apply.
Not in 2.15, not in 2.17.

-- 
David Kastrup