expected timeliness on glibc locale fixes

expected timeliness on glibc locale fixes

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

as we've been merging CLDR data in, a few claims have come up where
the CLDR data is incorrect/out of date.  assuming CLDR is incorrect
in these cases, how should we proceed ?  should we hot patch in the
request, or wait for the wheels of the CLDR machinations to turn and
then just pick up the next CLDR release ?  are there any cases where
the values are so egregiously wrong that we feel "it must be resolved
asap!" ?

i think it's safe to say that glibc long ago ceded the ground of
being an up-to-date source of locales.  so if we have a slightly
incorrect value for <1 year (from report time), is that a big deal ?
keep in mind we have bug reports now that are many years old and are
only now getting sorted out.

my take: push people to report defects to CLDR -- their tracker lets
you file reports w/out creating an account, so it's even simpler than
on our end.  it also means we are not the arbiters of messy political
issues and we don't have to do research ourselves (which is especially
time consuming for the vast majority of languages and territories that
have small / non-english internet presence).

i know this sounds like i'm making it harder for minority langs to be
represented, but by getting into CLDR, your impact is significantly
higher than glibc.  our track record here is also not that great ...
the bar has long been too high i think for people to get past, and i
don't think continuing to force people to file bug reports in our
bugzilla is the answer.  supporting other projects/outreaches which
have real people on the ground makes real differences.

note: this thread isn't about any specific request, nor do i have an
opinion either way about any of the claims (e.g. which is the most
correct/appropriate translation/value).  i want to focus on overall
and long term policies/procedures.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: expected timeliness on glibc locale fixes

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

On 18 Apr 2016 14:10, Mike Frysinger wrote:
> as we've been merging CLDR data in, a few claims have come up where
> the CLDR data is incorrect/out of date.  assuming CLDR is incorrect
> in these cases, how should we proceed ?  should we hot patch in the
> request, or wait for the wheels of the CLDR machinations to turn and
> then just pick up the next CLDR release ?  are there any cases where
> the values are so egregiously wrong that we feel "it must be resolved
> asap!" ?
> 
> i think it's safe to say that glibc long ago ceded the ground of
> being an up-to-date source of locales.  so if we have a slightly
> incorrect value for <1 year (from report time), is that a big deal ?
> keep in mind we have bug reports now that are many years old and are
> only now getting sorted out.
> 
> my take: push people to report defects to CLDR -- their tracker lets
> you file reports w/out creating an account, so it's even simpler than
> on our end.  it also means we are not the arbiters of messy political
> issues and we don't have to do research ourselves (which is especially
> time consuming for the vast majority of languages and territories that
> have small / non-english internet presence).
> 
> i know this sounds like i'm making it harder for minority langs to be
> represented, but by getting into CLDR, your impact is significantly
> higher than glibc.  our track record here is also not that great ...
> the bar has long been too high i think for people to get past, and i
> don't think continuing to force people to file bug reports in our
> bugzilla is the answer.  supporting other projects/outreaches which
> have real people on the ground makes real differences.
> 
> note: this thread isn't about any specific request, nor do i have an
> opinion either way about any of the claims (e.g. which is the most
> correct/appropriate translation/value).  i want to focus on overall
> and long term policies/procedures.

to help guide our decisions with some real data, i've started a page
which lists all known issues we've run into so far:
	https://sourceware.org/glibc/wiki/Locales/CLDR

if you know of more, please feel free to expand the list.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: expected timeliness on glibc locale fixes

[Florian Weimer]

On 04/18/2016 08:10 PM, Mike Frysinger wrote:
> as we've been merging CLDR data in, a few claims have come up where
> the CLDR data is incorrect/out of date.  assuming CLDR is incorrect
> in these cases, how should we proceed ?  should we hot patch in the
> request, or wait for the wheels of the CLDR machinations to turn and
> then just pick up the next CLDR release ?  are there any cases where
> the values are so egregiously wrong that we feel "it must be resolved
> asap!" ?

Does CLDR have a public bug tracker, so that we can see what is coming 
down the pipe?

Florian

Re: expected timeliness on glibc locale fixes

[Chris Leonard]

CLDR bugtracker
http://unicode.org/cldr/trac/report

On Mon, Apr 25, 2016 at 9:14 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 04/18/2016 08:10 PM, Mike Frysinger wrote:
>>
>> as we've been merging CLDR data in, a few claims have come up where
>> the CLDR data is incorrect/out of date.  assuming CLDR is incorrect
>> in these cases, how should we proceed ?  should we hot patch in the
>> request, or wait for the wheels of the CLDR machinations to turn and
>> then just pick up the next CLDR release ?  are there any cases where
>> the values are so egregiously wrong that we feel "it must be resolved
>> asap!" ?
>
>
> Does CLDR have a public bug tracker, so that we can see what is coming down
> the pipe?
>
> Florian
>