All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Erik Faye-Lund <kusmabite@gmail.com>
Subject: Re: Stable ab/i18n branch
Date: Thu, 14 Oct 2010 15:54:13 -0500	[thread overview]
Message-ID: <20101014205413.GD28958@burratino> (raw)
In-Reply-To: <AANLkTim-2V_XtWVLFbWS_A-0rFNmuDvtR58aanxKL-O2@mail.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

> 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.

  reply	other threads:[~2010-10-14 20:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-14  4:46 What's cooking in git.git (Oct 2010, #01; Wed, 13) Junio C Hamano
2010-10-14  5:51 ` Nazri Ramliy
2010-10-14  9:23 ` Ævar Arnfjörð Bjarmason
2010-10-14 20:00   ` Stable ab/i18n branch Jonathan Nieder
2010-10-14 20:44     ` Ævar Arnfjörð Bjarmason
2010-10-14 20:54       ` Jonathan Nieder [this message]
2010-10-14 21:18         ` Ævar Arnfjörð Bjarmason
2010-10-14 21:26           ` Sverre Rabbelier
2010-10-14 21:50           ` Jon Seymour
2010-10-15  4:54             ` Ævar Arnfjörð Bjarmason
2010-10-15  0:07           ` Jonathan Nieder
2010-10-15  5:16             ` Ævar Arnfjörð Bjarmason
2010-10-15  5:28               ` Jonathan Nieder
2010-10-15  5:35                 ` Ævar Arnfjörð Bjarmason
2010-10-17  4:44     ` Junio C Hamano
2010-10-17 12:33       ` Ævar Arnfjörð Bjarmason
2010-10-17 15:59         ` Jonathan Nieder
2010-10-18 23:39         ` Junio C Hamano
2010-10-19  6:05           ` Michael J Gruber
2010-10-17  4:43   ` What's cooking in git.git (Oct 2010, #01; Wed, 13) Junio C Hamano
2010-10-21  2:14 ` Johan Herland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101014205413.GD28958@burratino \
    --to=jrnieder@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kusmabite@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.