This is the mail archive of the
mailing list for the glibc project.
Re: Question: more languages to support alternative month names?
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Rafal Luzynski <digitalfreak at lingonborough dot com>, libc-alpha at sourceware dot org
- Date: Thu, 15 Feb 2018 13:30:26 -0800
- Subject: Re: Question: more languages to support alternative month names?
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
On 02/12/2018 05:45 PM, Rafal Luzynski wrote:
> Bug 10871 has been fixed and any language and any application can have
> a choice between two grammatical cases of the month names. But having
> a choice does not mean actually using it. I had only little more
> than one week between accepting the change by the community and the final
> release date so I was unable to contact every language community to
> ask about their opinion. Only 7 languages have been fixed so far while
> I have identified about 20 probably needing an update. 4 out of them
> probably don't want two grammatical cases. There are ~9 more languages
> who I'm contacting only now. It seems to me that at least few of them
> will want this change. So my question is: if they agree how to provide
> them the change:
> * push the change to master and tell them that they have to wait
> for glibc 2.28?
> * push the change both to 2.27 and 2.28?
> The first choice seems reasonable to me. Those 7 fixed languages
> have relatively large number of native speakers and the impact of the
> bug was rather large. Other languages either have low number of
> speakers and it's difficult to find people actually using them with
> computers or do not consider using an incorrect case as a language
> error or have working or almost working workarounds. So I think
> it's OK for them to wait a little more.
> Also, if we backport a change to a stable 2.27 release it is not
> obvious to me if the distributions actually apply the upstream
> patches to their binaries. What are your experiences?
You can do either option depending on how much free time you have.
Fedora *routinely* imports upstream release branches.
For example Fedora 28 will be based on glibc 2.27, and over the
6 months of support for Fedora 28 it will be updated routinely
from upstream release/2.27/master to pull in the latest fixes.
There are other distributions doing much the same, and I know Debian
probably also rebases on releases branches.
So you can do either.
As the localedata subsystem maintainer you can commit the fixes to
master and cherry-pick into 2.27 release branch immediately after.