expected timeliness on glibc locale fixes

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-locales/attachments/20160418/5396800d/attachment.sig>