glibc 2.29 - Winter is coming...

glibc 2.29 - Winter is coming...

[Siddhesh Poyarekar]

[OK, so winter doesn't quite mean freeze here in Pune but hey, y'all 
know what Im talking about right?!]

Hello!

I am a day late in announcing this but 2.29 code freeze is now in 
effect.  Only patches allowed during this window until release 
(scheduled on 1 Feb 2019) are bug fixes or regressions.  Patches that 
have been approved till now need to get in asap as well, lets target end 
of this week for this.

Status of Release blockers:

I have reviewed all original release blockers, including a couple of 
additional ones that got added later but I couldn't get to all of them. 
As of now, the pending blockers do not look suitable for inclusion at 
this stage and so will be deferred to 2.30 development.

A couple of patch series in the release blockers need some minor rework; 
those also need to close asap, preferably within this week so as to not 
impact testing.

I will send out pot files for translations later this week as well.

Siddhesh

Re: glibc 2.29 - Winter is coming...

[Florian Weimer]

* Siddhesh Poyarekar:

> I have reviewed all original release blockers, including a couple of
> additional ones that got added later but I couldn't get to all of
> them. As of now, the pending blockers do not look suitable for
> inclusion at this stage and so will be deferred to 2.30 development.

I support this decision, with the possible exception of “preserve
sprintf(buf, "%s", buf) behaviour” and “posix: Clear close-on-exec for
posix_spawn adddup2 (BZ#23640)”.

Thanks,
Florian

Re: glibc 2.29 - Winter is coming...

[Siddhesh Poyarekar]

On 02/01/19 4:29 PM, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> I have reviewed all original release blockers, including a couple of
>> additional ones that got added later but I couldn't get to all of
>> them. As of now, the pending blockers do not look suitable for
>> inclusion at this stage and so will be deferred to 2.30 development.
> 
> I support this decision, with the possible exception of “preserve
> sprintf(buf, "%s", buf) behaviour” and “posix: Clear close-on-exec for
> posix_spawn adddup2 (BZ#23640)”.

Both of those fall in the category of "I've reviewed them and expect 
them to be merged in by this week with the necessary changes".

Siddhesh

Re: glibc 2.29 - Winter is coming...

[Rafal Luzynski]

Siddhesh,

I have partially reviewed two patches but I don't know whether they are
correct or not and I've asked for more help or for freeze exceptions before:

[1] Cyrillic -> ASCII transliteration: I am not sure which locale should
implement the feature (C? Russian + few more? All locales with few
exceptions?),
also I am not sure how to deal with digraphs (if an original letter is
uppercase then should the output digraph be all uppercase, like "SH",
or should only the first letter be uppercase, like "Sh"?)  This may
happen to be the change in locale data only.

[2] [3] Default width for "%Ey" which is important due to the Japanese
era change in 4 months.  Also, this patch fixes handling of formatting
flags so if that helps it can be split into the patches fixing the width
issue and fixing the flags issue.

Regards,

Rafal


[1] https://sourceware.org/ml/libc-alpha/2018-12/msg00952.html
[2] https://sourceware.org/ml/libc-alpha/2018-12/msg00999.html
[3] https://sourceware.org/ml/libc-alpha/2018-12/msg00232.html

Re: glibc 2.29 - Winter is coming...

[Siddhesh Poyarekar]

On 02/01/19 5:22 PM, Rafal Luzynski wrote:
> I have partially reviewed two patches but I don't know whether they are
> correct or not and I've asked for more help or for freeze exceptions before:
> 
> [1] Cyrillic -> ASCII transliteration: I am not sure which locale should
> implement the feature (C? Russian + few more? All locales with few
> exceptions?),
> also I am not sure how to deal with digraphs (if an original letter is
> uppercase then should the output digraph be all uppercase, like "SH",
> or should only the first letter be uppercase, like "Sh"?)  This may
> happen to be the change in locale data only.

I've finally mustered up a bit of courage to read up and give my 
opinions on this, given that nobody else has.  My focus has been on 
breaking the deadlock because ISTM that the review is stuck on seemingly 
mundane issues that can either be trivially fixed up later or may not be 
as serious, such as the choice of implementing in C vs one of the Latin 
locales or the use of all-caps vs init-caps.

However, I am acutely aware that I may not understand the gravity of 
some of the differences and you're free to throw my opinions out the 
window :)

> [2] [3] Default width for "%Ey" which is important due to the Japanese
> era change in 4 months.  Also, this patch fixes handling of formatting
> flags so if that helps it can be split into the patches fixing the width
> issue and fixing the flags issue.

A more detailed explanation of what the Japanese era change entails is 
needed in here, i.e. why is the padding needed and what would the output 
look like if we don't fix it in this release and why that would be a 
problem.

Other than that, this seems like something we can make an exception for, 
assuming that it does not affect translations.  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.

Siddhesh

Re: glibc 2.29 - Winter is coming...

[Rafal Luzynski]

2.01.2019 19:24 Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 02/01/19 5:22 PM, Rafal Luzynski wrote:
> > [...]
> > [1] Cyrillic -> ASCII transliteration: I am not sure which locale should
> [...]
> However, I am acutely aware that I may not understand the gravity of 
> some of the differences and you're free to throw my opinions out the 
> window :)

Thank you, I will reply in the proper thread.

> > [2] [3] Default width for "%Ey" which is important due to the Japanese
> > era change in 4 months.  Also, this patch fixes handling of formatting
> > flags so if that helps it can be split into the patches fixing the width
> > issue and fixing the flags issue.
> 
> A more detailed explanation of what the Japanese era change entails is 
> needed in here, i.e. why is the padding needed

Each Japanese era year is the year of reign of the current emperor.
The current year is 31 (2 digits).  As soon as the new era is announced,
the new year will have the number 1 (one digit).  As far as I understood,
they do not want the year to be formatted as "1" but "01" instead because
they want to keep the constant width output for example in logs.
My reasoning is that "%y" is always zero-padded to 2 digits so for the
consistency let's set "%Ey" to be zero-padded to 2 digits as well.

The new Japanese era is already scheduled. [1]

> and what would the output 
> look like if we don't fix it in this release and why that would be a 
> problem.

For the comparison, here is the output of the current year and 1990 which
had the same problem:

$ LC_ALL=ja_JP.utf8 date +%Y
2019
$ LC_ALL=ja_JP.utf8 date +%EY
平成31年
$ LC_ALL=ja_JP.utf8 date +%Y -d "29 years ago"
1990
$ LC_ALL=ja_JP.utf8 date +%EY -d "29 years ago"
平成2年

I think they want: "平成02年".

An explanation why I use here "%Y" and "%EY" while we are talking
about "%Ey".  The reason is that "%EY" is expanded into a subformat which
may contain "%Ey" as the actual year number.

> 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.

Regards,

Rafal

[1] https://en.wikipedia.org/wiki/2019_Japanese_imperial_transition

Re: glibc 2.29 - Winter is coming...

[Carlos O'Donell]

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.

Re: glibc 2.29 - Winter is coming...

[Joseph Myers]

On Thu, 3 Jan 2019, Carlos O'Donell wrote:

> 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.

Presumably that includes the character properties for U+32FF?  (Does 
anything in glibc care about the to-be-announced compatibility 
decomposition that's the reason Unicode 12.1 will be needed 
<https://www.unicode.org/L2/L2018/18220-u121planning.txt> or is glibc only 
concerned with character properties that are already known?)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.29 - Winter is coming...

[Carlos O'Donell]

On 1/3/19 3:58 PM, Joseph Myers wrote:
> On Thu, 3 Jan 2019, Carlos O'Donell wrote:
> 
>> 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.
> 
> Presumably that includes the character properties for U+32FF?  (Does 
> anything in glibc care about the to-be-announced compatibility 
> decomposition that's the reason Unicode 12.1 will be needed 
> <https://www.unicode.org/L2/L2018/18220-u121planning.txt> or is glibc only 
> concerned with character properties that are already known?)

Yes, it should include the character properties for U+32FF (if possible).

Yes we care about compatibility decomposition when computing the
transliterated version of the Era name (see 
localedata/unicode-gen/gen_translit_compat.py (compatibility_decompose)).

I'm going to handle the Era name change myself when it arrives unless
someome beats me to it, we need it in RHEL.

I will limit the backport as much as I can to reduce risk.

-- 
Cheers,
Carlos.

Re: glibc 2.29 - Winter is coming...

[Florian Weimer]

* Joseph Myers:

> On Thu, 3 Jan 2019, Carlos O'Donell wrote:
>
>> 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.
>
> Presumably that includes the character properties for U+32FF?  (Does 
> anything in glibc care about the to-be-announced compatibility 
> decomposition that's the reason Unicode 12.1 will be needed 
> <https://www.unicode.org/L2/L2018/18220-u121planning.txt> or is glibc only 
> concerned with character properties that are already known?)

It seems that the CLDR data has a transliteration for the other era
characters.  I don't know how relevant this to glibc.

I'm pretty sure we need to adjust the collation data for U+32FF.

For the era data itself, we also need to know the multi-character era
name, so knowing the U+32FF codepoint is of little help (in the sense
that we can ship the changes today and have other projects to supply the
actual glyph shape).

Thanks,
Florian

Re: glibc 2.29 - Winter is coming...

[Gabriel F. T. Gomes]

On Wed, Jan 02 2019, Siddhesh Poyarekar wrote:
> On 02/01/19 4:29 PM, Florian Weimer wrote:
> > * Siddhesh Poyarekar:
> > 
> > > I have reviewed all original release blockers, including a couple of
> > > additional ones that got added later but I couldn't get to all of
> > > them. As of now, the pending blockers do not look suitable for
> > > inclusion at this stage and so will be deferred to 2.30 development.
> > 
> > I support this decision, with the possible exception of “preserve
> > sprintf(buf, "%s", buf) behaviour” and “posix: Clear close-on-exec for
> > posix_spawn adddup2 (BZ#23640)”.
> 
> Both of those fall in the category of "I've reviewed them and expect them to
> be merged in by this week with the necessary changes".

For the sprintf case, do we have consensus to commit the original patch
*with the test case*?  I think that the presence of the test case is
important to avoid future, *unintended* changes in behavior (its
presence does not imply that the behavior cannot change, only that it
will make the change more visible for reviewers), and commiting the test
case has an OK from Zack [1] and Joseph [2].  On the other hand, and as
pointed out by Siddhesh [3], Paul could have a sustained objection.

[1] https://sourceware.org/ml/libc-alpha/2018-12/msg00962.html
[2] https://sourceware.org/ml/libc-alpha/2018-12/msg01074.html
[3] https://sourceware.org/ml/libc-alpha/2018-12/msg01016.html

Re: glibc 2.29 - Winter is coming...

[Florian Weimer]

* Gabriel F. T. Gomes:

> On Wed, Jan 02 2019, Siddhesh Poyarekar wrote:
>> On 02/01/19 4:29 PM, Florian Weimer wrote:
>> > * Siddhesh Poyarekar:
>> > 
>> > > I have reviewed all original release blockers, including a couple of
>> > > additional ones that got added later but I couldn't get to all of
>> > > them. As of now, the pending blockers do not look suitable for
>> > > inclusion at this stage and so will be deferred to 2.30 development.
>> > 
>> > I support this decision, with the possible exception of “preserve
>> > sprintf(buf, "%s", buf) behaviour” and “posix: Clear close-on-exec for
>> > posix_spawn adddup2 (BZ#23640)”.
>> 
>> Both of those fall in the category of "I've reviewed them and expect them to
>> be merged in by this week with the necessary changes".
>
> For the sprintf case, do we have consensus to commit the original patch
> *with the test case*?  I think that the presence of the test case is
> important to avoid future, *unintended* changes in behavior (its
> presence does not imply that the behavior cannot change, only that it
> will make the change more visible for reviewers),

Agreed.

> and commiting the test
> case has an OK from Zack [1] and Joseph [2].  On the other hand, and as
> pointed out by Siddhesh [3], Paul could have a sustained objection.
>
> [1] https://sourceware.org/ml/libc-alpha/2018-12/msg00962.html
> [2] https://sourceware.org/ml/libc-alpha/2018-12/msg01074.html
> [3] https://sourceware.org/ml/libc-alpha/2018-12/msg01016.html

I think you can commit it now, considering that it has been reviewed
positively.

If the objection turns out to be of the sustained kind, we can still
back it out again before the release.

Thanks,
Florian

Re: glibc 2.29 - Winter is coming...

[Siddhesh Poyarekar]

On 02/01/19 6:46 PM, Florian Weimer wrote:
>> and commiting the test
>> case has an OK from Zack [1] and Joseph [2].  On the other hand, and as
>> pointed out by Siddhesh [3], Paul could have a sustained objection.
>>
>> [1] https://sourceware.org/ml/libc-alpha/2018-12/msg00962.html
>> [2] https://sourceware.org/ml/libc-alpha/2018-12/msg01074.html
>> [3] https://sourceware.org/ml/libc-alpha/2018-12/msg01016.html
> 
> I think you can commit it now, considering that it has been reviewed
> positively.
> 
> If the objection turns out to be of the sustained kind, we can still
> back it out again before the release.

Fair enough.

Siddhesh

Re: glibc 2.29 - Winter is coming...

[Gabriel F. T. Gomes]

On Wed, Jan 02 2019, Siddhesh Poyarekar wrote:
> On 02/01/19 6:46 PM, Florian Weimer wrote:
> > 
> > I think you can commit it now, considering that it has been reviewed
> > positively.
> > 
> > If the objection turns out to be of the sustained kind, we can still
> > back it out again before the release.
> 
> Fair enough.

Thanks, now committed.

Re: glibc 2.29 - Winter is coming...

[Szabolcs Nagy]

On 02/01/2019 10:28, Siddhesh Poyarekar wrote:
> Status of Release blockers:
> 
> I have reviewed all original release blockers, including a couple of additional ones that got added later but I couldn't get to all of them. As
> of now, the pending blockers do not look suitable for inclusion at this stage and so will be deferred to 2.30 development.

i'd like to commit some patches that only affect aarch64
(and only particular uarches there):

memchr and memset for AmpereComputing emag (approved before freeze):
https://sourceware.org/ml/libc-alpha/2018-12/msg00626.html
https://sourceware.org/ml/libc-alpha/2018-12/msg00628.html
https://sourceware.org/ml/libc-alpha/2018-12/msg00820.html

ifunc for ares (does not add new implementation):
https://sourceware.org/ml/libc-alpha/2018-12/msg00754.html

these seem safer to me to commit now than to backport them
later and should not interfere with the glibc release process.

Re: glibc 2.29 - Winter is coming...

[Carlos O'Donell]

On 1/8/19 8:33 AM, Szabolcs Nagy wrote:
> On 02/01/2019 10:28, Siddhesh Poyarekar wrote:
>> Status of Release blockers:
>>
>> I have reviewed all original release blockers, including a couple of additional ones that got added later but I couldn't get to all of them. As
>> of now, the pending blockers do not look suitable for inclusion at this stage and so will be deferred to 2.30 development.
> 
> i'd like to commit some patches that only affect aarch64
> (and only particular uarches there):
> 
> memchr and memset for AmpereComputing emag (approved before freeze):
> https://sourceware.org/ml/libc-alpha/2018-12/msg00626.html
> https://sourceware.org/ml/libc-alpha/2018-12/msg00628.html
> https://sourceware.org/ml/libc-alpha/2018-12/msg00820.html

AmpereComputing is not yet listed in the FSF copyright files,
and I don't have confirmation from the FSF (it has been asked).

> ifunc for ares (does not add new implementation):
> https://sourceware.org/ml/libc-alpha/2018-12/msg00754.html
> 
> these seem safer to me to commit now than to backport them
> later and should not interfere with the glibc release process. 

-- 
Cheers,
Carlos.

Re: glibc 2.29 - Winter is coming...

[Szabolcs Nagy]

On 08/01/2019 14:16, Carlos O'Donell wrote:
> On 1/8/19 8:33 AM, Szabolcs Nagy wrote:
>> On 02/01/2019 10:28, Siddhesh Poyarekar wrote:
>>> Status of Release blockers:
>>>
>>> I have reviewed all original release blockers, including a couple of additional ones that got added later but I couldn't get to all of them. As
>>> of now, the pending blockers do not look suitable for inclusion at this stage and so will be deferred to 2.30 development.
>>
>> i'd like to commit some patches that only affect aarch64
>> (and only particular uarches there):
>>
>> memchr and memset for AmpereComputing emag (approved before freeze):
>> https://sourceware.org/ml/libc-alpha/2018-12/msg00626.html
>> https://sourceware.org/ml/libc-alpha/2018-12/msg00628.html
>> https://sourceware.org/ml/libc-alpha/2018-12/msg00820.html
> 
> AmpereComputing is not yet listed in the FSF copyright files,
> and I don't have confirmation from the FSF (it has been asked).

ah, my bad then.

> 
>> ifunc for ares (does not add new implementation):
>> https://sourceware.org/ml/libc-alpha/2018-12/msg00754.html

this one still stands, i assume it's ok for me to commit it.

>>
>> these seem safer to me to commit now than to backport them
>> later and should not interfere with the glibc release process. 
> 

Re: glibc 2.29 - Winter is coming...

[Carlos O'Donell]

On 1/8/19 9:21 AM, Szabolcs Nagy wrote:
> On 08/01/2019 14:16, Carlos O'Donell wrote:
>> On 1/8/19 8:33 AM, Szabolcs Nagy wrote:
>>> On 02/01/2019 10:28, Siddhesh Poyarekar wrote:
>>>> Status of Release blockers:
>>>>
>>>> I have reviewed all original release blockers, including a couple of additional ones that got added later but I couldn't get to all of them. As
>>>> of now, the pending blockers do not look suitable for inclusion at this stage and so will be deferred to 2.30 development.
>>>
>>> i'd like to commit some patches that only affect aarch64
>>> (and only particular uarches there):
>>>
>>> memchr and memset for AmpereComputing emag (approved before freeze):
>>> https://sourceware.org/ml/libc-alpha/2018-12/msg00626.html
>>> https://sourceware.org/ml/libc-alpha/2018-12/msg00628.html
>>> https://sourceware.org/ml/libc-alpha/2018-12/msg00820.html
>>
>> AmpereComputing is not yet listed in the FSF copyright files,
>> and I don't have confirmation from the FSF (it has been asked).
> 
> ah, my bad then.

Sorry, my intent was only to specify that there is a blocker on
these patches. I am working with Feng Xue directly such that once
the copyright status is confirmed, I can move forward with account
setup so AmpereComputing can commit their own approved patches.

-- 
Cheers,
Carlos.

Re: glibc 2.29 - Winter is coming...

[Ramana Radhakrishnan]

On Tue, Jan 8, 2019 at 4:50 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 1/8/19 9:21 AM, Szabolcs Nagy wrote:
> > On 08/01/2019 14:16, Carlos O'Donell wrote:
> >> On 1/8/19 8:33 AM, Szabolcs Nagy wrote:
> >>> On 02/01/2019 10:28, Siddhesh Poyarekar wrote:
> >>>> Status of Release blockers:
> >>>>
> >>>> I have reviewed all original release blockers, including a couple of additional ones that got added later but I couldn't get to all of them. As
> >>>> of now, the pending blockers do not look suitable for inclusion at this stage and so will be deferred to 2.30 development.
> >>>
> >>> i'd like to commit some patches that only affect aarch64
> >>> (and only particular uarches there):
> >>>
> >>> memchr and memset for AmpereComputing emag (approved before freeze):
> >>> https://sourceware.org/ml/libc-alpha/2018-12/msg00626.html
> >>> https://sourceware.org/ml/libc-alpha/2018-12/msg00628.html
> >>> https://sourceware.org/ml/libc-alpha/2018-12/msg00820.html
> >>
> >> AmpereComputing is not yet listed in the FSF copyright files,
> >> and I don't have confirmation from the FSF (it has been asked).
> >
> > ah, my bad then.
>
> Sorry, my intent was only to specify that there is a blocker on
> these patches. I am working with Feng Xue directly such that once
> the copyright status is confirmed, I can move forward with account
> setup so AmpereComputing can commit their own approved patches.

I saw the copyright assignment go past on the GCC side when it
happened and see this in copyright.list on fencepost ..

GCC GLIBC       Ampere Computing LLC    2018-12-05
Assigns Past and Future Changes
Mauri Whalen (Vice President Software Engineering)

regards
Ramana


>
> --
> Cheers,
> Carlos.

Re: glibc 2.29 - Winter is coming...

[Carlos O'Donell]

On 1/9/19 5:50 AM, Ramana Radhakrishnan wrote:
> On Tue, Jan 8, 2019 at 4:50 PM Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 1/8/19 9:21 AM, Szabolcs Nagy wrote:
>>> On 08/01/2019 14:16, Carlos O'Donell wrote:
>>>> On 1/8/19 8:33 AM, Szabolcs Nagy wrote:
>>>>> On 02/01/2019 10:28, Siddhesh Poyarekar wrote:
>>>>>> Status of Release blockers:
>>>>>>
>>>>>> I have reviewed all original release blockers, including a couple of additional ones that got added later but I couldn't get to all of them. As
>>>>>> of now, the pending blockers do not look suitable for inclusion at this stage and so will be deferred to 2.30 development.
>>>>>
>>>>> i'd like to commit some patches that only affect aarch64
>>>>> (and only particular uarches there):
>>>>>
>>>>> memchr and memset for AmpereComputing emag (approved before freeze):
>>>>> https://sourceware.org/ml/libc-alpha/2018-12/msg00626.html
>>>>> https://sourceware.org/ml/libc-alpha/2018-12/msg00628.html
>>>>> https://sourceware.org/ml/libc-alpha/2018-12/msg00820.html
>>>>
>>>> AmpereComputing is not yet listed in the FSF copyright files,
>>>> and I don't have confirmation from the FSF (it has been asked).
>>>
>>> ah, my bad then.
>>
>> Sorry, my intent was only to specify that there is a blocker on
>> these patches. I am working with Feng Xue directly such that once
>> the copyright status is confirmed, I can move forward with account
>> setup so AmpereComputing can commit their own approved patches.
> 
> I saw the copyright assignment go past on the GCC side when it
> happened and see this in copyright.list on fencepost ..
> 
> GCC GLIBC       Ampere Computing LLC    2018-12-05
> Assigns Past and Future Changes
> Mauri Whalen (Vice President Software Engineering)

Correct, I saw this too and I'm working on the account setup.

-- 
Cheers,
Carlos.

Re: glibc 2.29 - Winter is coming...

[Carlos O'Donell]

On 1/23/19 8:40 AM, Feng Xue wrote:
> Now it is still in the stage of code freeze for 2.29 release, is it?
> And once window is opened that I can me to push those patches myself,
> should I need another code-review process on Patchwork?

Yes, master is frozen for the 2.29 release. The release is February 1st.

If the machine maintainers, particularly Szabolcs or Ramana have reviewed
the work and there appears to be consensus that it's correct, then you just
need to wait for the branch to open, Siddhesh will announce this, before
you push your changes.

Please use the ChangeLog as you wrote it with the date adjusted to the day 
you commit, use a detailed commit message (that was reviewed as part
of the submission), and remain attentive in the even that your change breaks
something and subsequent rework is needed.

Thank you!

-- 
Cheers,
Carlos.

Re: glibc 2.29 - Winter is coming...

[Siddhesh Poyarekar]

On 08/01/19 7:51 PM, Szabolcs Nagy wrote:
>>> ifunc for ares (does not add new implementation):
>>> https://sourceware.org/ml/libc-alpha/2018-12/msg00754.html
> 
> this one still stands, i assume it's ok for me to commit it.

I thought I had already approved it back then but I noticed that I only 
commented on the falkor quirk.  This is OK to commit.

Thanks,
Siddhesh