unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Rafal Luzynski <digitalfreak@lingonborough.com>,
	Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: GLIBC Devel <libc-alpha@sourceware.org>
Subject: Re: glibc 2.29 - Winter is coming...
Date: Thu, 3 Jan 2019 09:32:14 -0500	[thread overview]
Message-ID: <75bc5d8f-d568-d5e1-aacf-fa19beaac81b@redhat.com> (raw)
In-Reply-To: <2063591203.633198.1546474845289@poczta.nazwa.pl>

On 1/2/19 7:20 PM, Rafal Luzynski wrote:
> 2.01.2019 19:24 Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>> Other than that, this seems like something we can make an exception for, 
>> assuming that it does not affect translations.
> 
> It does not affect translations of glibc but does affect translations of
> applications to a minor extent: the zero-padded output is one character
> wider than the non-zero-padded one.  But:
> 
> * this is exactly what they want,
> * the output for the current year (and 21 previous years) is already the
> same wide as a zero-padded single digit year.
> 
>> I personally would have 
>> done 2 different patches, but I know others in the community who would 
>> have stuck this into a single patch so I don't have too strong an 
>> opinion about that aspect of this patch.
> 
> The other issue is that the additional flags like "%-EY" or "%_EY" are
> ignored.  I was going to say that this is not related with the era
> change but actually it is: as long as the year number had 2 digits
> those flags were correctly ignored.  Now the users will have a good
> reason to expect them to work correctly.

I think that this should be split into two patches immediately.

The "%-EY"/"%_EY" could go in as a bug fix right away.

The default for padding needs more review but could be given an exception
while we review the patch. I think both the patches should go in to 2.29, 
but need a little more work as Paul Eggert suggests.

They are important changes to get into 2.29 because of the Japanese Era
name change. Once the patches are in master they will allow the later
patches in April to be applied once the Era name is announced.

These changes are important to downstream enterprise distributions, but
in that case we only care that they land in master at some point. We want
a canonical solution that everyone is using.

The new Era name will likely have to be backported to all the active
open stable branches so they can display the new Era name.

-- 
Cheers,
Carlos.

  reply	other threads:[~2019-01-03 14:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-02 10:28 glibc 2.29 - Winter is coming Siddhesh Poyarekar
2019-01-02 10:59 ` Florian Weimer
2019-01-02 11:29   ` Siddhesh Poyarekar
2019-01-02 11:52     ` Rafal Luzynski
2019-01-02 18:24       ` Siddhesh Poyarekar
2019-01-03  0:20         ` Rafal Luzynski
2019-01-03 14:32           ` Carlos O'Donell [this message]
2019-01-03 20:58             ` Joseph Myers
2019-01-04 21:25               ` Carlos O'Donell
2019-01-07 18:59               ` Florian Weimer
2019-01-02 13:11     ` Gabriel F. T. Gomes
2019-01-02 13:16       ` Florian Weimer
2019-01-02 13:47         ` Siddhesh Poyarekar
2019-01-02 16:02           ` Gabriel F. T. Gomes
2019-01-08 13:33 ` Szabolcs Nagy
2019-01-08 14:16   ` Carlos O'Donell
2019-01-08 14:21     ` Szabolcs Nagy
2019-01-08 16:50       ` Carlos O'Donell
2019-01-09 10:50         ` Ramana Radhakrishnan
2019-01-09 16:03           ` Carlos O'Donell
     [not found]             ` <BL0PR01MB4593D75E9376CC15EE8CA24AF7990@BL0PR01MB4593.prod.exchangelabs.com>
2019-01-23 14:07               ` Carlos O'Donell
2019-01-09  5:48       ` Siddhesh Poyarekar

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

  List information: https://www.gnu.org/software/libc/involved.html

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

  git send-email \
    --in-reply-to=75bc5d8f-d568-d5e1-aacf-fa19beaac81b@redhat.com \
    --to=carlos@redhat.com \
    --cc=digitalfreak@lingonborough.com \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@gotplt.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).