Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> Ãvar ArnfjÃrà Bjarmason wrote:
>
>> Could you please pick up the 160 commit version of this at:
>>
>> git://github.com/avar/git.git ab/i18n
>
> This is a "give an inch and they'll ask for a mile" sort of thing, but
> would it be possible to maintain a stable branch with the i18n
> infrastructure that only gets rebased when there is reorganization
> going on?
People might have noticed that I've refrained to take other topics that
may add new messages to 'next'. I would wanted to merge ab/i18n early in
the cycle soon after dust has settled after 1.7.3 release. And I still
do.
Having said that, there are different classes of risks associated with
i18n effort.
(1) Regressions that even hit a NO_I18N build.
(2) Regressions that hit LC_ALL=C execution in a !NO_I18N build.
(3) Regressions that hit plumbing run in a non-C locale.
. i18n needs not just marking strings with _("string") but also needs to
fix code that manually formulates messages by series of strcat(). It
may need to start using allocations on the heap, with potential risk of
usual bugs (leaks, use-after-free, etc.) and performance degradation.
. Messages left unmarked with _("string"), or messages that are marked
with _("string") that shouldn't have, won't be serious issues for the
first two classes. The latter is a serious regression for the
plumbing.
We are all human, and misconversion during this process is possible, even
though the above classes of regressions are unacceptable. On the other
hand, as long as the above three classes of regressions are minimum and
quickly fixed/fixable, issues in non-C locale Porcelains are tolerable
during the initial cut.
I've looked at the patches in the series, and plan to take another look.
I'm sure others on the list have checked the series, some with fine combs,
too, and hopefully Ãvar has fixed any such regression that has been
reported and plans to do so for the ones discovered in the future. As
long as we are sure that we have done a reasonable effort to eyeball the
patches, the logical next step would be to merge the series to 'next' for
further testing.
(4) Incomplete *.po file, and languages without *.po file.
Once we are sure that the series does not have the first two classes of
issues, we can ask everybody to mark new strings in their series, iow,
merge the i18n part to 'master'. If we can do that sooner, it would be
better, and we do not need specific l10n part from the series during that
stage.
A language that already has *.po file may lack necessary translation;
there may be languages that do not have *.po file. They can be added with
a lot smaller risk later without unstabilizing the codebase.
So where are we now? I think a constantly rebased 160-patch series that
has infrastructure bits and l10n bits mixed together is not very friendly
to review for the first three classes of regressions (which are all I care
about at this point) to help the series hit 'master' sooner.
In any case, the branch merged to 'pu' has been replaced with the tip of
the said branch from Ãvar's repository now.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html