Re: Stable ab/i18n branch

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 14, 2010, 20:54 UTC
Message-ID: <20101014205413.GD28958@burratino>
In-Reply-To: <AANLkTim-2V_XtWVLFbWS_A-0rFNmuDvtR58aanxKL-O2@mail.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

Show 7 quoted lines

> I could do that, but I've been hoping that it just gets picked up for
> the `next -> master` process of git.git itself and *that* becomes the
> stable target.
> 
> But I have no idea what's going on at the other end, i.e. there's no
> comments about it in the "What's cooking in git.git" posts or
> elsewhere. So it's hard to know whether something like this is needed.

Probably it is a difference in culture between e.g. the Linux kernel and other projects. In the world I'll stereotype as the Linux kernel world, forks are considered good! Developments everyone agrees is good in the long run (like the Linux realtime tree) are not necessarily merged, for years even, the justification being that until the _immediate_ benefits for Linus outweigh the risks for Linus, it just doesn't make sense to merge.

This avoids bloat and bugs from code that is not being used by anyone, while allowing development to continue to happen.

Now git.git is not the Linux kernel. In particular, Junio provides the extra service of a working "proposed updates" branch, including changes that are not necessarily to be part of the next release. But the underlying principle is the same: until there is an _immediate_ benefit to including a feature in releases that does not outweigh the downsides, it just does not happen.

What that means: interested parties need to start testing the l10n code. There should be a reliable upstream for users of this feature and ideally that should not be Junio unless he wants to (and Ævar, I think you have been doing a good job of that, just saying it's valuable). The code's not going to get into shape otherwise.

> It's been about as ready as it's ever going to get for about a month
> now.

I hope not! e.g. the LC_CTYPE problems have not been resolved (and yes, that would be a regression for people using the it_IT.UTF-8 locale).

> I'm starting to get the feeling that there isn't much interest in i18n
> support at all.

I'm interested in it, at least.