From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-locales-return-4783-listarch-libc-locales=sources.redhat.com@sourceware.org>
Received: (qmail 86296 invoked by alias); 20 Dec 2016 16:00:35 -0000
Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-locales.sourceware.org>
List-Subscribe: <mailto:libc-locales-subscribe@sourceware.org>
List-Post: <mailto:libc-locales@sourceware.org>
List-Help: <mailto:libc-locales-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: libc-locales-owner@sourceware.org
Received: (qmail 86267 invoked by uid 89); 20 Dec 2016 16:00:35 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,LIKELY_SPAM_SUBJECT,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=sorting, aim, 56PM, 56pm
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: rap.rap.dk
Date: Tue, 20 Dec 2016 16:00:00 -0000
From: Keld Simonsen <keld@keldix.com>
To: carlos at redhat dot com <sourceware-bugzilla@sourceware.org>
Cc: libc-locales@sourceware.org
Subject: Re: [Bug localedata/20664] Unexpected collation in en_US.UTF-8,
 different to ICU CLDR
Message-ID: <20161220160001.GA6703@rap.rap.dk>
References: <bug-20664-716@http.sourceware.org/bugzilla/>
 <bug-20664-716-8uryFdUWGW@http.sourceware.org/bugzilla/>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <bug-20664-716-8uryFdUWGW@http.sourceware.org/bugzilla/>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SW-Source: 2016-q4/txt/msg00078.txt.bz2

On Mon, Oct 03, 2016 at 11:10:56PM +0000, carlos at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=20664
> 
> Carlos O'Donell <carlos at redhat dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |WAITING
>    Last reconfirmed|                            |2016-10-03
>                  CC|                            |carlos at redhat dot com
>      Ever confirmed|0                           |1
> 
> --- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
> Going forward we want glibc to track CLDR more closely. Therefore if you can
> find a glibc version that exhibits meaningful difference between CLDR, then
> please file a report, like this one.
> 
> However, you have too many moving pieces for us to validate this, for example
> sort is not a good test case because it might itself not use glibc's collation
> tables for sorting.
> 
> Can you construct a test case with strcoll that exhibits this problem?

I do not think we should aim at following CLDR closely, but we should minimize
differences. I actually think we should get CLDR to follow us more closely:-)

Bestregards
keld