icu-core — [Subscription only] Private core ICU developer discussion

[icu-core] PRI #434, Person Name Formatting

[Rick M. <ri...@un...>]

Hello everyone,

The CLDR committee would like to announce a new Public Review Issue 
around a proposed addition to UTS #35, the Unicode LDML specification, 
for Person Name Formatting.

Details of the proposal and instructions for providing feedback can be 
found on the PRI #434 page:

https://www.unicode.org/review/pri434/

Regards,

[icu-core] Would like to take ICU-21510

[David B. <dbe...@go...>]

I'd like to take:
https://unicode-org.atlassian.net/browse/ICU-21510

I have a PR ready to address it.

David

-- 
David Beaumont :: Îñţérñåţîöñåļîžåţîờñ Libraries :: Google
Google Switzerland GmbH., Brandschenkestrasse 110, CH-8002, Zürich -
Switzerland

[icu-core] would like to accept ICU-21537

[Frank T. (譚. <ft...@go...>]

Hi friends in ICU core

I would like to accept https://unicode-org.atlassian.net/browse/ICU-21537
It is a security issue discovered by google internally and can be
reproduced in public icu 69 trunk under ASAN. The crash happen when the
Collator::createInstance is given a very long Locale which the base is also
very long
I have test code and also the fix ready.

PR https://github.com/unicode-org/icu/pull/1656 is waiting for review.

-- 
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊
Sr. Software Engineer

Re: [icu-core] I would like to accept this ticket

[Markus S. <mar...@gm...>]

Yes, except that we first approved it for 69 if you could get it adjusted
by tomorrow, and then we moved the feature freeze to next week.
markus

[icu-core] I would like to accept this ticket

[Frank T. (譚. <ft...@go...>]

We discussed the API this morning

https://unicode-org.atlassian.net/browse/ICU-21490



-- 
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊
Sr. Software Engineer

[icu-core] ICU-20019

[Shane C. <sf...@go...>]

Dear friends,

I've been hard at work on ICU 69 features, and I sent out several proposals
in the past week.  There's one more which I plan to send shortly, for
ICU-20019 <https://unicode-org.atlassian.net/browse/ICU-20019>.  We need
this for the NumberFormat v3 proposal in ECMAScript, and delaying to ICU 70
would significantly delay the proposal.  I plan to send out this proposal
shortly, before next Wednesday's meeting, but I won't be able to get it out
in time for the full 5 day review period that we normally strive for.  I do
not anticipate this as causing any delay to ICU's release schedule.  Thanks
for your understanding.

Shane

[icu-core] Performance degradation scenarios in ICU

[Norbert R. <nr...@go...>]

This appeal was made during this mornings' ICU TC meeting, now sending it
to everyone on ICU Core:
If you have fixed time or memory degradation or have observed or been
notified of such degradations in the past please send the info to Craig and
Norbert. Include ticket# if available and, if fixed, PR#. Craig and Norbert
are looking into benchmarking to catch possible degradations before one of
the ICU users finds it. We start with resurrecting the performance tests in
source/test/perf/ but are also looking at issues encountered that may not
yet be covered by the performance tests.

Thank you,
Norbert

[icu-core] I would like to accept ICU-21462

[George R. <gr...@ap...>]

I would like to accept this issue.

https://unicode-org.atlassian.net/browse/ICU-21462 <https://unicode-org.atlassian.net/browse/ICU-21462>

ICULocaleService.java has a race condition as uncovered by Coverity.  It’s the only high impact issue listed in Coverity for ICU4J.

George

[icu-core] To propose a new API, what is the process?

[Victor C. <vi...@go...>]

Hi, ICU-TC,

I would like to propose a new API to modernize ubrk_safeClone.

Ticket: https://unicode-org.atlassian.net/browse/ICU-21455

What is the process? Should I attend the ICU-TC meeting and send the
proposal to icu-design?

The API proposal is creating a new API with a new name without 2 deprecated
parameters in ubrk_safeClone.
-- 

Victor Chang | Software Engineer | vi...@go...

Re: [icu-core] Would like to accept ICU-21430 for 68.2

[Markus S. <mar...@gm...>]

Oops -- too easy to make mistakes like this in C++...
I was probably the reviewer and didn't see this either. :-(

sg / tnx

markus

[icu-core] Would like to accept ICU-21430 for 68.2

[Frank T. (譚. <ft...@go...>]

I would like to accept this bug for 68.2. Two line changes. Somehow I
didn't mark the status as ref and the status was not returned ....

https://unicode-org.atlassian.net/browse/ICU-21430

-- 
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊
Sr. Software Engineer

Re: [icu-core] ICU CI is now super slow

[Steven R. L. <sr...@gm...>]

Check the Travis  status page i linked to. If there’s a backlog, that’s the
cause.

On Thu, Dec 3, 2020 at 3:29 PM Elango Cheran <el...@go...> wrote:

> I'm not sure if this is related to Travis being super slow, but a couple
> of ICU BRS task PRs seemed stalled on innocuous checks that should
> run/re-run and pass once they do, but they never get started. What they
> have in common is that the Travis check is the only other outstanding
> check, and it's stuck in "pending".
>
> https://github.com/unicode-org/icu/pull/1495
> https://github.com/unicode-org/icu/pull/1497
>
>
> On Thu, Dec 3, 2020 at 7:59 AM Steven R. Loomis <sr...@gm...> wrote:
>
>> If you trawl through the history of CLDR’s .github/workflows directory
>> you can find the ant-based and  now maven-based builds.  This would make
>> icu4j work well. If there’s interest I could hack up a ‘port’ of the Travis
>> builds.
>>
>> If Azure CI are working well, wouldn’t one quick option be to just make
>> Travis optional (not-required) but make Azure CI required?  Does Azure CI
>> already cover basic tests for C/J? If so, the path of least resistance is
>> to just use Azure CI.
>>
>> The Azure CI being paid, might mean at least priority support if
>> something’s stuck.
>>
>> -s
>>
>> On Thu, Dec 3, 2020 at 2:27 AM Jeff Genovy <jef...@gm...> wrote:
>>
>>> FWIW, there's also the option of adding more builds to the Azure CI
>>> pipelines as well. (IIRC, we're currently paying for ~200 parallel build
>>> lines, and I think we only have ~15 or so at the moment).
>>> But GitHub Actions is a good option as well. I believe the Free plan has
>>> ~20 parallel build lines.
>>> (The GitHub Actions YAML syntax/format is somewhat similar to the Azure
>>> CI YAML syntax as well, as I think it is the same system that runs both.
>>> However, the billing is, of course, different...)
>>>
>>> I'd probably dis-recommend AppVeyor though...
>>>
>>>
>>> On Wed, Dec 2, 2020 at 11:43 PM Shane Carr via icu-core <
>>> icu...@li...> wrote:
>>>
>>>> We use GitHub Actions in ICU4X and it seems to have been pretty
>>>> stable.  We also continue to have the option of using Google Cloud Build.
>>>>
>>>> On Thu, Dec 3, 2020 at 1:33 AM Frank Tang (譚永鋒) via icu-core <
>>>> icu...@li...> wrote:
>>>>
>>>>> The "active" went from about 500 on Nov 18 to 420 now - a 16%
>>>>> reduction . That probably increase the backlog
>>>>>
>>>>> https://en.wikipedia.org/wiki/Travis_CI
>>>>>
>>>>> In January 2019 it was announced that the company has been acquired by Idera,
>>>>> Inc. <https://en.wikipedia.org/wiki/Idera,_Inc.>[17]
>>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-17>
>>>>>
>>>>> A few weeks after the acquisition, a large portion of the old Travis
>>>>> team was fired.[18]
>>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-18>
>>>>>
>>>>> In March 2019 Travis CI infrastructure suffered massive outage that
>>>>> lasted from March 27 to March 29.[19]
>>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-19>[20]
>>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-20>
>>>>>
>>>>>
>>>>> https://devclass.com/2020/11/25/travis-ci-open-source-engagement/
>>>>>
>>>>> Especially users of the company’s free services started voicing
>>>>> discontent
>>>>> <https://twitter.com/maria_fibonacci/status/1330956656314814464> with
>>>>> the performance and overall quality of the tool, which is one of the
>>>>> reasons why there seems to be a wave of migration away from Travis CI over
>>>>> to GitHub Actions.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 2 Dec 2020 at 20:44, Steven R. Loomis <sr...@gm...>
>>>>> wrote:
>>>>>
>>>>>> It’s not just you.
>>>>>>
>>>>>> Thought we discussed this before on this list, but to recap:
>>>>>>
>>>>>> - you can check the backlog here
>>>>>> https://www.traviscistatus.com/ - the backlog should be nearly zero.
>>>>>>   6.5k / 10k means that things are stacking up, that’s why it takes a while.
>>>>>>
>>>>>> - i recommend github actions.  CLDR switched to that a few months
>>>>>> ago. it has had hiccups but has been more reliable overall.
>>>>>>
>>>>>> -s
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 2, 2020 at 7:37 PM Frank Tang (譚永鋒) via icu-core <
>>>>>> icu...@li...> wrote:
>>>>>>
>>>>>>> That is my question actually, is it just me?
>>>>>>>
>>>>>>> On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I did send an email to su...@tr... yesterday afternoon,
>>>>>>>> reporting the slow execution, asking if some bottleneck or similar is
>>>>>>>> happening, no response so far, though they did not respond to me before
>>>>>>>> when the issue went away.
>>>>>>>> Frank, do you still encounter extremely slow CI test times? Has
>>>>>>>> someone else encountered this problem? Coincidentally, on my on Travis CI
>>>>>>>> account (which monitors my forked ICU  repository, can recommend this) I
>>>>>>>> had a CI run on Monday
>>>>>>>> <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which
>>>>>>>> took not quite 1½ hrs which is OK, still less than the average
>>>>>>>> review time for my PRs.
>>>>>>>> I put this on the agenda next Wednesday: how big an issue for the
>>>>>>>> team, alternatives.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>    Norbert
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I push this PR 20 hours ago
>>>>>>>>>> https://github.com/unicode-org/icu/pull/1491
>>>>>>>>>> and half of the build/test are still queued
>>>>>>>>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>>>>>>>>
>>>>>>>>>> The latency is now unbearable slow.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Frank
>>>>>>>>>> --
>>>>>>>>>> Frank Yung-Fong Tang
>>>>>>>>>> 譚永鋒 / 🌭🍊
>>>>>>>>>> Sr. Software Engineer
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nebojša Ćirić
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Frank Yung-Fong Tang
>>>>>>> 譚永鋒 / 🌭🍊
>>>>>>> Sr. Software Engineer
>>>>>>> _______________________________________________
>>>>>>> icu-core mailing list
>>>>>>> icu...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Frank Yung-Fong Tang
>>>>> 譚永鋒 / 🌭🍊
>>>>> Sr. Software Engineer
>>>>> _______________________________________________
>>>>> icu-core mailing list
>>>>> icu...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>>>
>>>> _______________________________________________
>>>> icu-core mailing list
>>>> icu...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>>
>>> _______________________________________________
>>> icu-core mailing list
>>> icu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>
>> _______________________________________________
>> icu-core mailing list
>> icu...@li...
>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>
>

[icu-core] sunsetting the icu-core mailing list

[Markus S. <mar...@gm...>]

Hi team,

Let's say goodbye to the icu-core SourceForge mailing list.
For future team-internal emails please send to icu...@un....

If you are not in that Google Group yet, then you didn't reply to me (shame
on you) and I didn't think of you when I added some more people (shame on
me). If so, reply to me off-list :-)

See you on the other side --
markus

Re: [icu-core] ICU CI is now super slow

[Elango C. <el...@go...>]

I'm not sure if this is related to Travis being super slow, but a couple of
ICU BRS task PRs seemed stalled on innocuous checks that should run/re-run
and pass once they do, but they never get started. What they have in common
is that the Travis check is the only other outstanding check, and it's
stuck in "pending".

https://github.com/unicode-org/icu/pull/1495
https://github.com/unicode-org/icu/pull/1497


On Thu, Dec 3, 2020 at 7:59 AM Steven R. Loomis <sr...@gm...> wrote:

> If you trawl through the history of CLDR’s .github/workflows directory you
> can find the ant-based and  now maven-based builds.  This would make icu4j
> work well. If there’s interest I could hack up a ‘port’ of the Travis
> builds.
>
> If Azure CI are working well, wouldn’t one quick option be to just make
> Travis optional (not-required) but make Azure CI required?  Does Azure CI
> already cover basic tests for C/J? If so, the path of least resistance is
> to just use Azure CI.
>
> The Azure CI being paid, might mean at least priority support if
> something’s stuck.
>
> -s
>
> On Thu, Dec 3, 2020 at 2:27 AM Jeff Genovy <jef...@gm...> wrote:
>
>> FWIW, there's also the option of adding more builds to the Azure CI
>> pipelines as well. (IIRC, we're currently paying for ~200 parallel build
>> lines, and I think we only have ~15 or so at the moment).
>> But GitHub Actions is a good option as well. I believe the Free plan has
>> ~20 parallel build lines.
>> (The GitHub Actions YAML syntax/format is somewhat similar to the Azure
>> CI YAML syntax as well, as I think it is the same system that runs both.
>> However, the billing is, of course, different...)
>>
>> I'd probably dis-recommend AppVeyor though...
>>
>>
>> On Wed, Dec 2, 2020 at 11:43 PM Shane Carr via icu-core <
>> icu...@li...> wrote:
>>
>>> We use GitHub Actions in ICU4X and it seems to have been pretty stable.
>>> We also continue to have the option of using Google Cloud Build.
>>>
>>> On Thu, Dec 3, 2020 at 1:33 AM Frank Tang (譚永鋒) via icu-core <
>>> icu...@li...> wrote:
>>>
>>>> The "active" went from about 500 on Nov 18 to 420 now - a 16% reduction
>>>> . That probably increase the backlog
>>>>
>>>> https://en.wikipedia.org/wiki/Travis_CI
>>>>
>>>> In January 2019 it was announced that the company has been acquired by Idera,
>>>> Inc. <https://en.wikipedia.org/wiki/Idera,_Inc.>[17]
>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-17>
>>>>
>>>> A few weeks after the acquisition, a large portion of the old Travis
>>>> team was fired.[18]
>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-18>
>>>>
>>>> In March 2019 Travis CI infrastructure suffered massive outage that
>>>> lasted from March 27 to March 29.[19]
>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-19>[20]
>>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-20>
>>>>
>>>>
>>>> https://devclass.com/2020/11/25/travis-ci-open-source-engagement/
>>>>
>>>> Especially users of the company’s free services started voicing
>>>> discontent
>>>> <https://twitter.com/maria_fibonacci/status/1330956656314814464> with
>>>> the performance and overall quality of the tool, which is one of the
>>>> reasons why there seems to be a wave of migration away from Travis CI over
>>>> to GitHub Actions.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 2 Dec 2020 at 20:44, Steven R. Loomis <sr...@gm...> wrote:
>>>>
>>>>> It’s not just you.
>>>>>
>>>>> Thought we discussed this before on this list, but to recap:
>>>>>
>>>>> - you can check the backlog here
>>>>> https://www.traviscistatus.com/ - the backlog should be nearly zero.
>>>>>   6.5k / 10k means that things are stacking up, that’s why it takes a while.
>>>>>
>>>>> - i recommend github actions.  CLDR switched to that a few months ago.
>>>>> it has had hiccups but has been more reliable overall.
>>>>>
>>>>> -s
>>>>>
>>>>>
>>>>> On Wed, Dec 2, 2020 at 7:37 PM Frank Tang (譚永鋒) via icu-core <
>>>>> icu...@li...> wrote:
>>>>>
>>>>>> That is my question actually, is it just me?
>>>>>>
>>>>>> On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...> wrote:
>>>>>>
>>>>>>> I did send an email to su...@tr... yesterday afternoon,
>>>>>>> reporting the slow execution, asking if some bottleneck or similar is
>>>>>>> happening, no response so far, though they did not respond to me before
>>>>>>> when the issue went away.
>>>>>>> Frank, do you still encounter extremely slow CI test times? Has
>>>>>>> someone else encountered this problem? Coincidentally, on my on Travis CI
>>>>>>> account (which monitors my forked ICU  repository, can recommend this) I
>>>>>>> had a CI run on Monday
>>>>>>> <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which
>>>>>>> took not quite 1½ hrs which is OK, still less than the average
>>>>>>> review time for my PRs.
>>>>>>> I put this on the agenda next Wednesday: how big an issue for the
>>>>>>> team, alternatives.
>>>>>>>
>>>>>>> Regards,
>>>>>>>    Norbert
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I push this PR 20 hours ago
>>>>>>>>> https://github.com/unicode-org/icu/pull/1491
>>>>>>>>> and half of the build/test are still queued
>>>>>>>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>>>>>>>
>>>>>>>>> The latency is now unbearable slow.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Frank
>>>>>>>>> --
>>>>>>>>> Frank Yung-Fong Tang
>>>>>>>>> 譚永鋒 / 🌭🍊
>>>>>>>>> Sr. Software Engineer
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nebojša Ćirić
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Frank Yung-Fong Tang
>>>>>> 譚永鋒 / 🌭🍊
>>>>>> Sr. Software Engineer
>>>>>> _______________________________________________
>>>>>> icu-core mailing list
>>>>>> icu...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Frank Yung-Fong Tang
>>>> 譚永鋒 / 🌭🍊
>>>> Sr. Software Engineer
>>>> _______________________________________________
>>>> icu-core mailing list
>>>> icu...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>>
>>> _______________________________________________
>>> icu-core mailing list
>>> icu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>
>> _______________________________________________
>> icu-core mailing list
>> icu...@li...
>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>
> _______________________________________________
> icu-core mailing list
> icu...@li...
> https://lists.sourceforge.net/lists/listinfo/icu-core
>

Re: [icu-core] ICU CI is now super slow

[Steven R. L. <sr...@gm...>]

If you trawl through the history of CLDR’s .github/workflows directory you
can find the ant-based and  now maven-based builds.  This would make icu4j
work well. If there’s interest I could hack up a ‘port’ of the Travis
builds.

If Azure CI are working well, wouldn’t one quick option be to just make
Travis optional (not-required) but make Azure CI required?  Does Azure CI
already cover basic tests for C/J? If so, the path of least resistance is
to just use Azure CI.

The Azure CI being paid, might mean at least priority support if
something’s stuck.

-s

On Thu, Dec 3, 2020 at 2:27 AM Jeff Genovy <jef...@gm...> wrote:

> FWIW, there's also the option of adding more builds to the Azure CI
> pipelines as well. (IIRC, we're currently paying for ~200 parallel build
> lines, and I think we only have ~15 or so at the moment).
> But GitHub Actions is a good option as well. I believe the Free plan has
> ~20 parallel build lines.
> (The GitHub Actions YAML syntax/format is somewhat similar to the Azure CI
> YAML syntax as well, as I think it is the same system that runs both.
> However, the billing is, of course, different...)
>
> I'd probably dis-recommend AppVeyor though...
>
>
> On Wed, Dec 2, 2020 at 11:43 PM Shane Carr via icu-core <
> icu...@li...> wrote:
>
>> We use GitHub Actions in ICU4X and it seems to have been pretty stable.
>> We also continue to have the option of using Google Cloud Build.
>>
>> On Thu, Dec 3, 2020 at 1:33 AM Frank Tang (譚永鋒) via icu-core <
>> icu...@li...> wrote:
>>
>>> The "active" went from about 500 on Nov 18 to 420 now - a 16% reduction
>>> . That probably increase the backlog
>>>
>>> https://en.wikipedia.org/wiki/Travis_CI
>>>
>>> In January 2019 it was announced that the company has been acquired by Idera,
>>> Inc. <https://en.wikipedia.org/wiki/Idera,_Inc.>[17]
>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-17>
>>>
>>> A few weeks after the acquisition, a large portion of the old Travis
>>> team was fired.[18]
>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-18>
>>>
>>> In March 2019 Travis CI infrastructure suffered massive outage that
>>> lasted from March 27 to March 29.[19]
>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-19>[20]
>>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-20>
>>>
>>>
>>> https://devclass.com/2020/11/25/travis-ci-open-source-engagement/
>>>
>>> Especially users of the company’s free services started voicing
>>> discontent
>>> <https://twitter.com/maria_fibonacci/status/1330956656314814464> with
>>> the performance and overall quality of the tool, which is one of the
>>> reasons why there seems to be a wave of migration away from Travis CI over
>>> to GitHub Actions.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, 2 Dec 2020 at 20:44, Steven R. Loomis <sr...@gm...> wrote:
>>>
>>>> It’s not just you.
>>>>
>>>> Thought we discussed this before on this list, but to recap:
>>>>
>>>> - you can check the backlog here
>>>> https://www.traviscistatus.com/ - the backlog should be nearly zero.
>>>> 6.5k / 10k means that things are stacking up, that’s why it takes a while.
>>>>
>>>> - i recommend github actions.  CLDR switched to that a few months ago.
>>>> it has had hiccups but has been more reliable overall.
>>>>
>>>> -s
>>>>
>>>>
>>>> On Wed, Dec 2, 2020 at 7:37 PM Frank Tang (譚永鋒) via icu-core <
>>>> icu...@li...> wrote:
>>>>
>>>>> That is my question actually, is it just me?
>>>>>
>>>>> On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...> wrote:
>>>>>
>>>>>> I did send an email to su...@tr... yesterday afternoon,
>>>>>> reporting the slow execution, asking if some bottleneck or similar is
>>>>>> happening, no response so far, though they did not respond to me before
>>>>>> when the issue went away.
>>>>>> Frank, do you still encounter extremely slow CI test times? Has
>>>>>> someone else encountered this problem? Coincidentally, on my on Travis CI
>>>>>> account (which monitors my forked ICU  repository, can recommend this) I
>>>>>> had a CI run on Monday
>>>>>> <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which
>>>>>> took not quite 1½ hrs which is OK, still less than the average
>>>>>> review time for my PRs.
>>>>>> I put this on the agenda next Wednesday: how big an issue for the
>>>>>> team, alternatives.
>>>>>>
>>>>>> Regards,
>>>>>>    Norbert
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I push this PR 20 hours ago
>>>>>>>> https://github.com/unicode-org/icu/pull/1491
>>>>>>>> and half of the build/test are still queued
>>>>>>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>>>>>>
>>>>>>>> The latency is now unbearable slow.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Frank
>>>>>>>> --
>>>>>>>> Frank Yung-Fong Tang
>>>>>>>> 譚永鋒 / 🌭🍊
>>>>>>>> Sr. Software Engineer
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nebojša Ćirić
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Frank Yung-Fong Tang
>>>>> 譚永鋒 / 🌭🍊
>>>>> Sr. Software Engineer
>>>>> _______________________________________________
>>>>> icu-core mailing list
>>>>> icu...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>>>
>>>>
>>>
>>> --
>>> Frank Yung-Fong Tang
>>> 譚永鋒 / 🌭🍊
>>> Sr. Software Engineer
>>> _______________________________________________
>>> icu-core mailing list
>>> icu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>
>> _______________________________________________
>> icu-core mailing list
>> icu...@li...
>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>
> _______________________________________________
> icu-core mailing list
> icu...@li...
> https://lists.sourceforge.net/lists/listinfo/icu-core
>

Re: [icu-core] ICU CI is now super slow

[Jeff G. <jef...@gm...>]

FWIW, there's also the option of adding more builds to the Azure CI
pipelines as well. (IIRC, we're currently paying for ~200 parallel build
lines, and I think we only have ~15 or so at the moment).
But GitHub Actions is a good option as well. I believe the Free plan has
~20 parallel build lines.
(The GitHub Actions YAML syntax/format is somewhat similar to the Azure CI
YAML syntax as well, as I think it is the same system that runs both.
However, the billing is, of course, different...)

I'd probably dis-recommend AppVeyor though...


On Wed, Dec 2, 2020 at 11:43 PM Shane Carr via icu-core <
icu...@li...> wrote:

> We use GitHub Actions in ICU4X and it seems to have been pretty stable.
> We also continue to have the option of using Google Cloud Build.
>
> On Thu, Dec 3, 2020 at 1:33 AM Frank Tang (譚永鋒) via icu-core <
> icu...@li...> wrote:
>
>> The "active" went from about 500 on Nov 18 to 420 now - a 16% reduction .
>> That probably increase the backlog
>>
>> https://en.wikipedia.org/wiki/Travis_CI
>>
>> In January 2019 it was announced that the company has been acquired by Idera,
>> Inc. <https://en.wikipedia.org/wiki/Idera,_Inc.>[17]
>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-17>
>>
>> A few weeks after the acquisition, a large portion of the old Travis team
>> was fired.[18] <https://en.wikipedia.org/wiki/Travis_CI#cite_note-18>
>>
>> In March 2019 Travis CI infrastructure suffered massive outage that
>> lasted from March 27 to March 29.[19]
>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-19>[20]
>> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-20>
>>
>>
>> https://devclass.com/2020/11/25/travis-ci-open-source-engagement/
>>
>> Especially users of the company’s free services started voicing
>> discontent
>> <https://twitter.com/maria_fibonacci/status/1330956656314814464> with
>> the performance and overall quality of the tool, which is one of the
>> reasons why there seems to be a wave of migration away from Travis CI over
>> to GitHub Actions.
>>
>>
>>
>>
>>
>>
>> On Wed, 2 Dec 2020 at 20:44, Steven R. Loomis <sr...@gm...> wrote:
>>
>>> It’s not just you.
>>>
>>> Thought we discussed this before on this list, but to recap:
>>>
>>> - you can check the backlog here
>>> https://www.traviscistatus.com/ - the backlog should be nearly zero.
>>> 6.5k / 10k means that things are stacking up, that’s why it takes a while.
>>>
>>> - i recommend github actions.  CLDR switched to that a few months ago.
>>> it has had hiccups but has been more reliable overall.
>>>
>>> -s
>>>
>>>
>>> On Wed, Dec 2, 2020 at 7:37 PM Frank Tang (譚永鋒) via icu-core <
>>> icu...@li...> wrote:
>>>
>>>> That is my question actually, is it just me?
>>>>
>>>> On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...> wrote:
>>>>
>>>>> I did send an email to su...@tr... yesterday afternoon,
>>>>> reporting the slow execution, asking if some bottleneck or similar is
>>>>> happening, no response so far, though they did not respond to me before
>>>>> when the issue went away.
>>>>> Frank, do you still encounter extremely slow CI test times? Has
>>>>> someone else encountered this problem? Coincidentally, on my on Travis CI
>>>>> account (which monitors my forked ICU  repository, can recommend this) I
>>>>> had a CI run on Monday
>>>>> <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which
>>>>> took not quite 1½ hrs which is OK, still less than the average review
>>>>> time for my PRs.
>>>>> I put this on the agenda next Wednesday: how big an issue for the
>>>>> team, alternatives.
>>>>>
>>>>> Regards,
>>>>>    Norbert
>>>>>
>>>>>
>>>>> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...>
>>>>>> wrote:
>>>>>>
>>>>>>> I push this PR 20 hours ago
>>>>>>> https://github.com/unicode-org/icu/pull/1491
>>>>>>> and half of the build/test are still queued
>>>>>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>>>>>
>>>>>>> The latency is now unbearable slow.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Frank
>>>>>>> --
>>>>>>> Frank Yung-Fong Tang
>>>>>>> 譚永鋒 / 🌭🍊
>>>>>>> Sr. Software Engineer
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nebojša Ćirić
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Frank Yung-Fong Tang
>>>> 譚永鋒 / 🌭🍊
>>>> Sr. Software Engineer
>>>> _______________________________________________
>>>> icu-core mailing list
>>>> icu...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>>
>>>
>>
>> --
>> Frank Yung-Fong Tang
>> 譚永鋒 / 🌭🍊
>> Sr. Software Engineer
>> _______________________________________________
>> icu-core mailing list
>> icu...@li...
>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>
> _______________________________________________
> icu-core mailing list
> icu...@li...
> https://lists.sourceforge.net/lists/listinfo/icu-core
>

Re: [icu-core] ICU CI is now super slow

[Shane C. <sf...@go...>]

We use GitHub Actions in ICU4X and it seems to have been pretty stable.  We
also continue to have the option of using Google Cloud Build.

On Thu, Dec 3, 2020 at 1:33 AM Frank Tang (譚永鋒) via icu-core <
icu...@li...> wrote:

> The "active" went from about 500 on Nov 18 to 420 now - a 16% reduction .
> That probably increase the backlog
>
> https://en.wikipedia.org/wiki/Travis_CI
>
> In January 2019 it was announced that the company has been acquired by Idera,
> Inc. <https://en.wikipedia.org/wiki/Idera,_Inc.>[17]
> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-17>
>
> A few weeks after the acquisition, a large portion of the old Travis team
> was fired.[18] <https://en.wikipedia.org/wiki/Travis_CI#cite_note-18>
>
> In March 2019 Travis CI infrastructure suffered massive outage that lasted
> from March 27 to March 29.[19]
> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-19>[20]
> <https://en.wikipedia.org/wiki/Travis_CI#cite_note-20>
>
>
> https://devclass.com/2020/11/25/travis-ci-open-source-engagement/
>
> Especially users of the company’s free services started voicing discontent
> <https://twitter.com/maria_fibonacci/status/1330956656314814464> with the
> performance and overall quality of the tool, which is one of the reasons
> why there seems to be a wave of migration away from Travis CI over to
> GitHub Actions.
>
>
>
>
>
>
> On Wed, 2 Dec 2020 at 20:44, Steven R. Loomis <sr...@gm...> wrote:
>
>> It’s not just you.
>>
>> Thought we discussed this before on this list, but to recap:
>>
>> - you can check the backlog here
>> https://www.traviscistatus.com/ - the backlog should be nearly zero.
>> 6.5k / 10k means that things are stacking up, that’s why it takes a while.
>>
>> - i recommend github actions.  CLDR switched to that a few months ago. it
>> has had hiccups but has been more reliable overall.
>>
>> -s
>>
>>
>> On Wed, Dec 2, 2020 at 7:37 PM Frank Tang (譚永鋒) via icu-core <
>> icu...@li...> wrote:
>>
>>> That is my question actually, is it just me?
>>>
>>> On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...> wrote:
>>>
>>>> I did send an email to su...@tr... yesterday afternoon,
>>>> reporting the slow execution, asking if some bottleneck or similar is
>>>> happening, no response so far, though they did not respond to me before
>>>> when the issue went away.
>>>> Frank, do you still encounter extremely slow CI test times? Has someone
>>>> else encountered this problem? Coincidentally, on my on Travis CI account
>>>> (which monitors my forked ICU  repository, can recommend this) I had a CI
>>>> run on Monday
>>>> <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which took
>>>> not quite 1½ hrs which is OK, still less than the average review time
>>>> for my PRs.
>>>> I put this on the agenda next Wednesday: how big an issue for the team,
>>>> alternatives.
>>>>
>>>> Regards,
>>>>    Norbert
>>>>
>>>>
>>>> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...>
>>>>> wrote:
>>>>>
>>>>>> I push this PR 20 hours ago
>>>>>> https://github.com/unicode-org/icu/pull/1491
>>>>>> and half of the build/test are still queued
>>>>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>>>>
>>>>>> The latency is now unbearable slow.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Frank
>>>>>> --
>>>>>> Frank Yung-Fong Tang
>>>>>> 譚永鋒 / 🌭🍊
>>>>>> Sr. Software Engineer
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nebojša Ćirić
>>>>>
>>>>
>>>
>>> --
>>> Frank Yung-Fong Tang
>>> 譚永鋒 / 🌭🍊
>>> Sr. Software Engineer
>>> _______________________________________________
>>> icu-core mailing list
>>> icu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>>
>>
>
> --
> Frank Yung-Fong Tang
> 譚永鋒 / 🌭🍊
> Sr. Software Engineer
> _______________________________________________
> icu-core mailing list
> icu...@li...
> https://lists.sourceforge.net/lists/listinfo/icu-core
>

Re: [icu-core] ICU CI is now super slow

[Frank T. (譚. <ft...@go...>]

The "active" went from about 500 on Nov 18 to 420 now - a 16% reduction .
That probably increase the backlog

https://en.wikipedia.org/wiki/Travis_CI

In January 2019 it was announced that the company has been acquired by Idera,
Inc. <https://en.wikipedia.org/wiki/Idera,_Inc.>[17]
<https://en.wikipedia.org/wiki/Travis_CI#cite_note-17>

A few weeks after the acquisition, a large portion of the old Travis team
was fired.[18] <https://en.wikipedia.org/wiki/Travis_CI#cite_note-18>

In March 2019 Travis CI infrastructure suffered massive outage that lasted
from March 27 to March 29.[19]
<https://en.wikipedia.org/wiki/Travis_CI#cite_note-19>[20]
<https://en.wikipedia.org/wiki/Travis_CI#cite_note-20>


https://devclass.com/2020/11/25/travis-ci-open-source-engagement/

Especially users of the company’s free services started voicing discontent
<https://twitter.com/maria_fibonacci/status/1330956656314814464> with the
performance and overall quality of the tool, which is one of the reasons
why there seems to be a wave of migration away from Travis CI over to
GitHub Actions.






On Wed, 2 Dec 2020 at 20:44, Steven R. Loomis <sr...@gm...> wrote:

> It’s not just you.
>
> Thought we discussed this before on this list, but to recap:
>
> - you can check the backlog here
> https://www.traviscistatus.com/ - the backlog should be nearly zero.
> 6.5k / 10k means that things are stacking up, that’s why it takes a while.
>
> - i recommend github actions.  CLDR switched to that a few months ago. it
> has had hiccups but has been more reliable overall.
>
> -s
>
>
> On Wed, Dec 2, 2020 at 7:37 PM Frank Tang (譚永鋒) via icu-core <
> icu...@li...> wrote:
>
>> That is my question actually, is it just me?
>>
>> On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...> wrote:
>>
>>> I did send an email to su...@tr... yesterday afternoon,
>>> reporting the slow execution, asking if some bottleneck or similar is
>>> happening, no response so far, though they did not respond to me before
>>> when the issue went away.
>>> Frank, do you still encounter extremely slow CI test times? Has someone
>>> else encountered this problem? Coincidentally, on my on Travis CI account
>>> (which monitors my forked ICU  repository, can recommend this) I had a CI
>>> run on Monday
>>> <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which took
>>> not quite 1½ hrs which is OK, still less than the average review time
>>> for my PRs.
>>> I put this on the agenda next Wednesday: how big an issue for the team,
>>> alternatives.
>>>
>>> Regards,
>>>    Norbert
>>>
>>>
>>> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...>
>>>> wrote:
>>>>
>>>>> I push this PR 20 hours ago
>>>>> https://github.com/unicode-org/icu/pull/1491
>>>>> and half of the build/test are still queued
>>>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>>>
>>>>> The latency is now unbearable slow.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Frank
>>>>> --
>>>>> Frank Yung-Fong Tang
>>>>> 譚永鋒 / 🌭🍊
>>>>> Sr. Software Engineer
>>>>>
>>>>
>>>>
>>>> --
>>>> Nebojša Ćirić
>>>>
>>>
>>
>> --
>> Frank Yung-Fong Tang
>> 譚永鋒 / 🌭🍊
>> Sr. Software Engineer
>> _______________________________________________
>> icu-core mailing list
>> icu...@li...
>> https://lists.sourceforge.net/lists/listinfo/icu-core
>>
>

-- 
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊
Sr. Software Engineer

Re: [icu-core] ICU CI is now super slow

[Steven R. L. <sr...@gm...>]

It’s not just you.

Thought we discussed this before on this list, but to recap:

- you can check the backlog here
https://www.traviscistatus.com/ - the backlog should be nearly zero.   6.5k
/ 10k means that things are stacking up, that’s why it takes a while.

- i recommend github actions.  CLDR switched to that a few months ago. it
has had hiccups but has been more reliable overall.

-s


On Wed, Dec 2, 2020 at 7:37 PM Frank Tang (譚永鋒) via icu-core <
icu...@li...> wrote:

> That is my question actually, is it just me?
>
> On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...> wrote:
>
>> I did send an email to su...@tr... yesterday afternoon,
>> reporting the slow execution, asking if some bottleneck or similar is
>> happening, no response so far, though they did not respond to me before
>> when the issue went away.
>> Frank, do you still encounter extremely slow CI test times? Has someone
>> else encountered this problem? Coincidentally, on my on Travis CI account
>> (which monitors my forked ICU  repository, can recommend this) I had a CI
>> run on Monday <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which
>> took not quite 1½ hrs which is OK, still less than the average review
>> time for my PRs.
>> I put this on the agenda next Wednesday: how big an issue for the team,
>> alternatives.
>>
>> Regards,
>>    Norbert
>>
>>
>> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...> wrote:
>>
>>>
>>>
>>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...>
>>> wrote:
>>>
>>>> I push this PR 20 hours ago
>>>> https://github.com/unicode-org/icu/pull/1491
>>>> and half of the build/test are still queued
>>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>>
>>>> The latency is now unbearable slow.
>>>>
>>>>
>>>> Regards,
>>>> Frank
>>>> --
>>>> Frank Yung-Fong Tang
>>>> 譚永鋒 / 🌭🍊
>>>> Sr. Software Engineer
>>>>
>>>
>>>
>>> --
>>> Nebojša Ćirić
>>>
>>
>
> --
> Frank Yung-Fong Tang
> 譚永鋒 / 🌭🍊
> Sr. Software Engineer
> _______________________________________________
> icu-core mailing list
> icu...@li...
> https://lists.sourceforge.net/lists/listinfo/icu-core
>

Re: [icu-core] ICU CI is now super slow

[Frank T. (譚. <ft...@go...>]

That is my question actually, is it just me?

On Wed, 2 Dec 2020 at 17:17, Norbert Runge <nr...@go...> wrote:

> I did send an email to su...@tr... yesterday afternoon,
> reporting the slow execution, asking if some bottleneck or similar is
> happening, no response so far, though they did not respond to me before
> when the issue went away.
> Frank, do you still encounter extremely slow CI test times? Has someone
> else encountered this problem? Coincidentally, on my on Travis CI account
> (which monitors my forked ICU  repository, can recommend this) I had a CI
> run on Monday <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which
> took not quite 1½ hrs which is OK, still less than the average review
> time for my PRs.
> I put this on the agenda next Wednesday: how big an issue for the team,
> alternatives.
>
> Regards,
>    Norbert
>
>
> On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...> wrote:
>
>>
>>
>> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...> wrote:
>>
>>> I push this PR 20 hours ago https://github.com/unicode-org/icu/pull/1491
>>> and half of the build/test are still queued
>>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>>
>>> The latency is now unbearable slow.
>>>
>>>
>>> Regards,
>>> Frank
>>> --
>>> Frank Yung-Fong Tang
>>> 譚永鋒 / 🌭🍊
>>> Sr. Software Engineer
>>>
>>
>>
>> --
>> Nebojša Ćirić
>>
>

-- 
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊
Sr. Software Engineer

Re: [icu-core] ICU CI is now super slow

[Norbert R. <nr...@go...>]

I did send an email to su...@tr... yesterday afternoon, reporting
the slow execution, asking if some bottleneck or similar is happening, no
response so far, though they did not respond to me before when the issue
went away.
Frank, do you still encounter extremely slow CI test times? Has someone
else encountered this problem? Coincidentally, on my on Travis CI account
(which monitors my forked ICU  repository, can recommend this) I had a CI
run on Monday <https://travis-ci.com/github/gnrunge/icu/builds/205469670> which
took not quite 1½ hrs which is OK, still less than the average review time
for my PRs.
I put this on the agenda next Wednesday: how big an issue for the team,
alternatives.

Regards,
   Norbert


On Tue, Dec 1, 2020 at 5:38 PM Nebojša Ćirić <ci...@go...> wrote:

>
>
> On Tue, Dec 1, 2020 at 5:00 PM Frank Tang (譚永鋒) <ft...@go...> wrote:
>
>> I push this PR 20 hours ago https://github.com/unicode-org/icu/pull/1491
>> and half of the build/test are still queued
>> https://travis-ci.org/github/unicode-org/icu/builds/746905653
>>
>> The latency is now unbearable slow.
>>
>>
>> Regards,
>> Frank
>> --
>> Frank Yung-Fong Tang
>> 譚永鋒 / 🌭🍊
>> Sr. Software Engineer
>>
>
>
> --
> Nebojša Ćirić
>

[icu-core] Commits on Master but not Maint-68

[Shane C. <sf...@go...>]

Please review the following list.

*Tickets whose fix-version is 68*

+ af7ed1f6d2298013dc303628438ec4abe1f16479 ICU-21326 Changed
res_findResource() so that it doesn't try index-based lookup in a table
resource if the resource ID has a leading zero
+ 57820a495de92b8364ee7390ec86a92d3540d763 ICU-21337 Remove U_I18N_API from
enum.
+ 35e950d35fea0cad481205981344c4983469e22f ICU-21387 measunit: check for
nullptr before calling delete

*Tickets whose fix-version is 69 but maybe should be 68?*

+ 275d59aa2addd5b88432e7b871ad002e5fefedde ICU-21410 fix int32_t overflow
in listFormat
+ 0ab995ec84a31be12f669a156c59c3eaba39f10f ICU-21408 Prohibit alpha4 as
language inside tlang.
+ 1aa229daff95302f87f2abe6355aaf6e57a5df80 ICU-21402 replace sd and rg by
subdivisionAlias
+ d0096a84e78149c110ef775608e60869af0fa2c8 ICU-21243 Migrates
preparseucd.py script to Python 3. Python 3 changes the order of elements
in an iterator from Python 2 with the result that the genera

*Tickets whose fix-version is 69*

+ 0439cc5f7beceb3bdf95815e8a8b75f21bd11e05 ICU-21311 Fix code generation in
MeasureUnitTest.java and use it
+ 21dde41f9e2c2b72ae7aea2018e1dcf05655934d ICU-21349 Some improvements to
UnitsTest
+ 7c8f857da820506b061604db21a6bbd3ec908f0f ICU-21356 Fix memory handling in
MemoryPool::operator=()
+ 710fa5aaf9a155f67a9995911dbe8d5c40b56458 ICU-20941 Support formatting
joule-per-furlong (builtin-per-builtin).
+ 5a753752226851d2c2cb40ce443bc383e65459e4 ICU-21349 Refactor
testComplexUnitsConverter
+ 0912b8519376a1630ea72abd677fb0d30b9c3205 ICU-10997 Port test case for
10997 currency formatting to icu4c
+ 50f3d015530781dc9719565ad3f0a81ef3ae4de0 ICU-21361 Add public PGP key
+ 7c9bad02d26a59466c760a28989f7045c8f133ad ICU-21366 testConverter: allow
some double-precision error for 0.0
+ 909f343cd6db8da64db3562d261dad85f7444430 ICU-21349 Improve MeasureUnit
comparators
+ 50bd7969c794f8c1999f55e5cb77aaff3f4fc4ac ICU-21349 Remove a potential 0/0
(=NaN). Align C++ & Java better.
+ f7ab1f7c5007e53993fc3b907ababf5b04ce22bc ICU-21349 Fix confusing names of
exponent variables.
+ 916f6a0b734a829157b81c0fee67b07c0e977427 ICU-21401 Fix C++ canonicalize
cel-gaulish to xtg
+ 6ad0ece0346fc2ecda2327ec9c5304475e3d860a ICU-21381 AppVeyor CI Builds:
Speed up the Cygwin setup download.
+ 3d706fac426fe4b4ac5e84b21a8f3bcb4eb5953e ICU-21349 fix comment for CLDR
identifiers
+ 917188dc7f838348ab341f0b85e789668d6c2f90 ICU-21306 Pull CLDR 38's unit
prefixes into ICU
+ c07264a363dbdbaa28ecc15633ef05764b1d2afe ICU-21349 Make appendSingleUnit
behaviour in C++ comply with Java

[icu-core] ICU CI is now super slow

[Frank T. (譚. <ft...@go...>]

I push this PR 20 hours ago https://github.com/unicode-org/icu/pull/1491
and half of the build/test are still queued
https://travis-ci.org/github/unicode-org/icu/builds/746905653

The latency is now unbearable slow.


Regards,
Frank
-- 
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊
Sr. Software Engineer

Re: [icu-core] Would like to accept this bug

[Mark D. ☕️ <ma...@ma...>]

OT: I hate that the Markdowns all have different syntax...
Mark


On Mon, Nov 30, 2020 at 5:19 PM Markus Scherer <mar...@gm...> wrote:

> sgtm
>
> Note that in the Jira ticket description ``` does not work :-)
>
> markus
> _______________________________________________
> icu-core mailing list
> icu...@li...
> https://lists.sourceforge.net/lists/listinfo/icu-core
>

Re: [icu-core] Would like to accept this bug

[Markus S. <mar...@gm...>]

sgtm

Note that in the Jira ticket description ``` does not work :-)

markus