ICU-TC Meeting Minutes 2015-2016 (Archived)

Current and past meeting minutes

2016/12/21 and 2016/12/28 - No meetings

http://grammarist.com/spelling/cancel/

2016/12/14

1. ICU 58.2 was released on Dec 9
2. ICU 59m1 schedule (Peter)

1. CLDR data structure freeze - Jan 14
2. ICU59m1 date: Wed Feb 1, 2017, about 2 weeks after CLDR structure freeze
3. (tag only) release manager

1. Peter - http://bugs.icu-project.org/trac/ticket/12895 - linked from http://bugs.icu-project.org/trac/milestone/59m1

4. Pick up new data structure from CLDR which should be done mid-Jan
5. Set m1 for Feb 1

3. ICU-TC Summit (Steven)

1. Monday January 30, 2017 - at Google campus(?) – Markus still working on it :-/
2. Agenda - separate shared doc

1. Put all proposed agenda by Jan 11, ICU TC call
2. Jan 11 call - we'll finalize topics/time slots

4. C++11 switch-over (andy)

1. which features? https://github.com/nodejs/node/issues/7844#issuecomment-239273083
2. http://bugs.icu-project.org/trac/ticket/12643
3. Turn on C++11, migrate to UString at the first step
4. Other C++11 features are evaluated incrementally

5. ICU is officially in Windows, will be in January insider flights

1. Exposed to developers
2. Native C APIs only / so (should be) backward compatible
3. http://www.icu-project.org/repos/icu/trunk/icu4c/readme.html#RecBuild including “ICU as a System-Level Library”

6. Incoming

2016/12/07

(Peter will be out for this one)

1. ICU 58.2

1. CLDR 30.0.3 data was integrated into trunk per #12876, merge to maint branch?
2. 59m1 bugs with keyword maint

1. #12869 Don't use ordinal() to define public constants ???
2. Numeric values unchanged from before

3. Who is going to merge -> Yoshito
4. Steven to prepare C src/binaries
5. Yoshito to prepare J
6. Release date - Friday Dec 9th

2. Steven - walkthrough of Jenkins build.

1. https://cldr-build.unicode.org/jenkins/
2. icu4c build for trunk checks out only icu4c portion of trunk
3. For shared testdata, we will need to check out the whole trunk and then cd into icu4c for build & test
4. Could have trunk builds that build & test both c & j (new build script)
5. change trigger builds to mid-build not post-build [srl]

3. MessageFormat dtskeleton vs. datetimeskeleton vs. skeleton vs. dts ... (Markus)

1. http://bugs.icu-project.org/trac/ticket/9622#comment:14
2. “The due date is {duedate, dts, yMMMd}.”
3. Consensus: dts

4. MessageFormat formatted constants pre-proposal (Markus)

1. Opinions? Ready to go to icu-design?
2. No objections; Markus will turn it into a real proposal and send to icu-design.

5. Locale/LanguageMatcher

1. https://docs.google.com/document/d/1wRfFjvg80lU6bx6kaq25BBiNuQaA7IIiu6h5qG63b0s/edit#heading=h.14e2w2syinu3 

6. “Sensitive” tickets

1. per doc above - unembargo 1 release after released
2. create 'sensitive' group - for packagers who can get read access
3. Steven to add BRS items and maintain list of packagers with read access

7. Incoming

2016/11/30

1. ICU 58.2

1. current target: Dec 7 (next week)
2. 59m1 bugs with keyword maint

1. #12849 u_strToTitle returns incorrect length if destination is NULL ?

3. CLDR#9924 Still wrong: Population data for Cantonese (yue) speakers

1. Mark will fix this today/tomorrow, Peter to roll into branch and tag the version in CLDR svn
2. ICU does not use the data, except example code
3. If we pick this one, it will need ICU4J 58.2 as well.

4. CLDR #9925 - kMandarin value for some chars not being used correctly by Friday.
5. CLDR 30.0.3 (svn tag only)
6. CLDR TC Friday call on this Friday - should have some updates from Mark at that point

2. ICU-TC Summit (Steven)

1. set date - Fri Jan 20th or Mon Jan 30th? —  Mark, PeterE ?

1. prefer jan20:
2. prefer jan30: Markus, Mark
3. Agreed - Monday January 30, 2017

2. location?

1. Google? Markus to investigate

3. Headcount?

1. IBM: 1-2 (+1 remote)
2. Google: 3+ (need to find out more)
3. Apple: 1-2 (Peter remote)
4. Microsoft: 1-2
5. Others: (regular contributors…)

4. Agenda - separate shared doc

3. Deprecate ICU’s encoding detector in favor of the compact encoding detector (CED) (https://github.com/google/compact_enc_det) [Mark]

1. [yoshito] Does ICU4C support language detection???
2. [andy] No. As a side-effect of charset detection, it will guess a language for a few encodings, but it is not generally useful, not reliable, and doesn’t work at all for many encodings.
3. Andy: ICU charset detector has real users, and it detects EBCDIC charsets which the CED does not
4. Agreement: Mark to file a ticket for documentation (not really actively developing it, may mention other libraries), but not deprecating the APIs
5. Andy: could have shim code (call one from the other, for comparison/compatibility)

1. …which is what we did for layout engine

4. Incoming

2016/11/23 - Cancelled

1. Wednesday just before US Thanksgiving holiday. People not available: Yoshito, Markus, Peter, Andy

2016/11/16

1. Host environment preferences - update and next steps (Zibi)
2. ICU 58.2 (ICU4C only) - 59m1 bugs with keyword maint 

1. (fixed) #12815 ICU4C uspoof_getSkeleton sets backwards-incompatible illegal argument exception
2. (fixed) #12825 uspoof_check goes into an "infinite loop" when U+30FB is in an input string
3. (fixed) #12822 digitlist.cpp won't compile on msvc under Node.js
4. (fixed) #12832 GreekUpper:toUpper skips the final character on a non-terminated UTF-8 string
5. #12849 u_strToTitle returns incorrect length if destination is NULL
6. Minor version policy with C/J combined trunk.

1. With separate C,J used to do n.n.1 for updates only to C or J, n.2 for both.
2. Now with combined tags: Use n.2, includes C++ changes but Java stays the same. Java binaries not updated, continue to report n.1 version. If later Java needs an update, we roll n.3, update Java binaries but don’t touch C++ so C++ will continue to report n.2 then. Say this on the “n” download page.
3. http://semver.org - good reading on version #s (Steven)

1. (+ when breaking changes).(+ when add functionality in compatible way).(+ when fix bugs)
2. major: ICU: tries not to make breaking changes. But we could count data changes.
3. minor: ICU doesn't add functionality except in major versions
4. (when we had numbers such as "4.8.1.1" people thought going from 3.8 to 4.0 was a major jump, which is why we changed to bump the major number)

4. Policy (ICU 58+)

1. First field - is major release
2. Second field - is minor (maint) release which is published
3. Third field - may be tag-only patch which is not published
4. ICU-TC never uses the 4th field - reserved for packager/end user

7. Release target Date: Dec 7 (Wed)

1. icu4c dist builds: https://cldr-build.unicode.org/jenkins/job/icu/job/icu4c-dist/

8. http://bugs.icu-project.org/trac/milestone/58.2

3. Build status (Steven)

1. out with the old… ( 1000lb of stuff being recycled today… Bitten on skeleton crew of builders )
2. …in with the new   ( jenkins - OSUOSL  (ppc linux), marist ( zLinux ) Azure ( master / win10 ) ,

1. Future: GCC Compile Farm
2. stability issues
3. Steven todo: how to see what the status is. what to chase down.

4. ICU API Proposal from Jeff Walden (Mozilla): unum_formatDoubleForFields()

1. Email to icu-design 2016-10-28
2. http://bugs.icu-project.org/trac/ticket/12684
3. ICU 59 API proposal status
4. Approved, Peter to respond on icu-design list

5. ICU-TC long term planning (Steven)

1. two prongs

1. ICU-TC core
2. bringing in additional Collaborators

2. inspiration - https://github.com/nodejs/summit
3. recommendation - Unicode EMG
4. topics

1. review process (pre-submit review, rietveld, etc)
2. direction
3. other language interaction (Javascript, … )
4. Discuss at: separate shared doc

5. logistics

1. ~ IUC, UTC
2. f2f ideal - or video conf
3. bay area - when people are in town?
4. more than once a year
5. could do it around UTC when Mark is stateside
6. http://www.unicode.org/timesens/calendar.html

1. week (friday?) before or (monday?) after UTC # 150 (Jan 23-26) / Unicode BoD Meeting (Jan. 27)? / Unicode EMG offsite spillover (Jan 28th )
2. Fri Jan 20th or Mon Jan 30th? —  Mark, PeterE ?
3. TODO(markus): Host at Google?

6. Incoming

2016/11/09 - Let's have a short call

1. (During UTC meeting; not available: Steven, Peter, Mark, Markus)
2. SVN repository reorg

1. C/J trunk is merged into a single root
2. tags/branches?

1. Maint branches 50 thru 58 are moved
2. Tags release 50 thru 58 are copied
3. 49 and older?

3. CLDR utilities jar

1. CLDR wants utilites.jar from the ICU trunk, but test framework classes from 57 because of JUnit migration is not read in CLDR

1. Update trunk to generates utilities.jar excluding test framework
2. Is it OK to update maint-57 to produce two separate jars?

4. Incoming

2016/11/02 IUC 40 - cancelled

http://www.unicodeconference.org/program.htm

2016/10/26 9:45 America/Los_Angeles

1. Next two meetings
2. ICU 58.1

1. BRS 58 - all done?
2. merge milestone 58m1 to 58.1 - Markus done oct26
3. Closing 58.1 milestone - move tickets to 59 - done oct26

3. Markus: Do we need milestones?

1. Very few orgs pick them up for integration & testing (mostly the winter milestone?)
2. Forcing function for due diligence, good checkpoint
3. Stable cut, useful for porting
4. Do light BRS and tag, but don’t need to publish anything, no download page
5. Import structure from CLDR

4. 58.1 windows build issue found during nodejs integration - http://bugs.icu-project.org/trac/ticket/12822

1. merge to maint-58? - yes

5. PluralRules and fractional 0: http://bugs.icu-project.org/trac/ticket/12763

1. Best for now: input (number, NumberFormat) → output (formatted string, plural form) – comment added to ticket

6. Host environment preferences (context: https://github.com/tc39/ecma402/issues/109)

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1308329

7. Review for http://bugs.icu-project.org/trac/ticket/12684

1. http://site.icu-project.org/processes/proposal-template
2. First step is to propose new draft API using process in API Proposal Email Template
3. Then we schedule a review in ICU meeting, at least a week after
4. Once API is approved, can do implementation and have code review for implementation

8. Svn repository reorg. Timing?
9. Incoming

2016/10/19

1. ICU 58.1

1. BRS 58
2. Please review changes merged to maint-58

1. http://bugs.icu-project.org/trac/review/12779
2. http://bugs.icu-project.org/trac/review/12780

3. Should we merge #12798 (Andy's security fix) to ICU4C 58.1?

1. Markus: yes (it includes a not-Cygwin bug fix)
2. Peter: yes
3. Steven will merge & tag - ticket:12779

1. merged: r39471
2. tag : r39472
3. ticket set for review

4. ICU4J tagged / ICU4C tagged
5. 58 download page

1. Mark will try to add something about impact of some changes

6. Yoshito will post ICU4J release binaries/API doc tonight
7. Steven - ICU4C
8. Release announcement - draft today, send to team, then to Rick & editorial committee

2. Updating Win7/ibm-ultra4 ? (Currently Win/perf build not useful) [Peter]

1. Yes - in progress (Steven)

3. ICU svn reorg (Andy) - http://bugs.icu-project.org/trac/ticket/12800

1. Add text on the repository page about old vs. new layout: http://site.icu-project.org/repository
2. Start next week, announce closing of repository to icu-core

4. ICU contributors documentation (see email discussion “cleaning up web pages on license”) [Mark]

1. http://site.icu-project.org/processes/contribute
2. http://userguide.icu-project.org/dev/contributions
3. If you want to join the team, then please contact us. Once everything is agreed, the ICU team gives you an ICU server account for svn write access, and an ICU Trac account for ticket (bugs/features) management.
4. Mark’s suggestion:

1. If your company has already filed a CLA, then contact your company's representative to get authorization for ICU accounts: an ICU server account for svn write access, and an ICU Trac account for ticket (bugs/features) management. If you want to be an active individual contributor, please contact us.

5. Steven: Do ICU team members need to be Unicode members?
6. PMC? We don’t really have a defined process any more for how to join etc.; PMC used to vote, PMC as such does not really exist any more, now we have ICU-TC chair & vice chair.

5. CLDR meeting time was shortened to end at 9:30 PT, Mark mentioned possibly moving the ICU meeting earlier (9:45 PT?)

1. Ok: 9:45-11:00 Pacific Time starting next week

6. IUC 40 “New in ICU” feedback? See email to icu-core.
7. Incoming

2016/10/12

1. ICU 58.1

1. BRS 58
2. ICU4J trunk changes not yet merged to 58.1 stream

1. #11950 / r39429 multi-threaded Java tests - Won't be merged to 58.1

1. This change seems to trigger intermittent TimeZoneFormatTest failure on Solaris?? - see http://bugs.icu-project.org/trac/build/icu4j
2. (Yoshito) I'm the reviewer. The ticket is closed now. But not sure I'm aware of this.

2. #12759 / r39430 Test file bigdec/DiagBigDecimal.java not converted to Junit - will be merged to 58.1
3. #12797 / r39431 RBBI, bug in $variable substitution during rule compilation - merge
4. #12792 / r39435 ICU4J unit tests in CalendarRegression.java, MessageRegression.java, and TimeZoneRegression.java are not executed - will be merged to 58.1 - merge

3. ICU4C trunk changes not yet merged to 58.1 stream

1. #12797 / r39432 RBBI, bug in $variable substitution during rule compilation

4. CLDR 30.0.1 release, integrate into ICU 58 (Peter)

1. Ticket #12801 (also addresses #12791, the Myanmar name issue)
2. CLDR Bugs to fix
3. Pick up additional CLDR locales for ICU:
           de_IT
           nds [low German/low Saxon], nds_DE, nds_NL
           es_BR
           pt_CH, pt_GQ [Equatorial Guinea], pt_LU [Luxembourg]
                   CH, 3.4% of population speaks pt
                   LU, 16% of population speaks pt (see Wikipedia)
           ckb [Sorani Kurdish], ckb_IQ, ckb_IR

2. Revised most of the description of http://bugs.icu-project.org/trac/ticket/12607. More changes?
3. Incoming

2016/10/05

1. ICU 58

1. Release plan update

1. ICU 58.1 GA on Friday Oct 21 (previous - Oct 14)
2. This version will merge at least CLDR#9843 (Myanmar country name), plus a few more CLDR fixes
3. 58RC download page to list tickets which will be merged into GA version

2. CLDR 30 release today. No data changes from the release-30-d05 tag integrated into ICU.

1. One or more known CLDR data issues that we may want to fix in ICU; need CLDR dot release?

1. ICU #12791 incorrect “my” name for “MM”, CLDR #9843
2. Possibly a fix for Basque day periods?
3. CLDR dot release - tag only (30-1)?
4. Markus: A tag like cldr-30-with-fixes off of the cldr-30 maintenance branch (?!) is probably fine.
5. Steven: we can discuss in CLDR, also if there are additional changes that come in. CLDR doesn't usually make a maint branch. I'd like it to have a real v number such as 30.0.1 if possible

3. Review

1. Tickets in review state
2. Tickets with trunk changes / not under review

4. BRS 58
5. Merge watch - C

1. 12778 - DONE detect mmap on cygwin srl 

1. mac: OK, merged to tmp branch, r39419
2. trunk: r39424 (misticketted -comment  should be 'mmap')

2. 12781 - DONE dirent on cygwin srl

1. mac: OK, merged to tmp branch, r39418
2. trunk: r39423

3. 12783 - DONE umutex on cygwin srl

1. mac: OK, merged to tmp branch, r39417
2. trunk: r39422

4. 12773 - DONE digitlist on cygwin (strtod_l) srl

1. cyg: merged, compile in progress…

1. Fail: intltest format/TimeZoneTest/TestGenericAPI
2.          FAIL: detectHostTimeZone()'s raw offset != host timezone's offset
3. Does not seem to be caused by this specific patch.
4. r39420 with all patches - passes on cygwin.

2. trunk: r39425

5. 12774 - DONE tzname/timezone checks on cygwin srl

1.  ( unchecked on cygwin. ok mac. on tmp branch r39416) 
2. trunk: r39421

6. ticket:12771 DONE r39408 - © statements
7. r39427 : merges r39408 r39421 r39422 r39423 r39424 r39425 from trunk into maint-58

6.  #12759 Java BigDecimal test invocation / Not merged
7. ICU 58 Compatibility with Windows XP and Vista

1. Anyone aware of changes that make it not work on those Windows versions any more? - still works
2. Shawn: It might be worth mentioning in the release notes that this will be the last ICU version to support Windows XP? People that read such things would at least then be forewarned.

1. Mentioned on the download page, not in the release notes.

2. merge old ICU milestone releases into final releases (Markus)

1. I would like to merge 57m1 into 57.1, 56m1 into 56.1, etc.
2. Details see email 20160930
3. TC agreed to merge milestones into past releases

3. Incoming

2016/09/28

1. ICU 58 RC

1. Review

1. Tickets in review state
2. Tickets with trunk changes / not under review

2. BRS 58
3. Remaining issues

1. ICU4J trunk coverage is broken:  #12716 / r39372 ccornelius - Yoshito will fix (thanks!) and also fix hashCode() API docs and regen API change report
2. 12752  - srl - z porting - before RC tag
3. tzdata2016g

4. 58 download page

2. Incoming

2016/09/21

1. API promotion (@draft 56 or older to @stable)

1. Andy: ICU4C

1. hold as @draft for ones not neede with C++11
2. measure unit factory - CLDR tooling should manage the status/version

2. Yoshito: ICU4J

1. draft API change report
2. SpoofChecker: @Deprecated public String getSkeleton(int, CharSequence) -> @Deprecated public String getSkeleton(int, String)

1. Was String, Shane widened to CharSequence while deprecating, Yoshito said that’s not necessary, Shane changed it back to String: r39305

2. ErrorProne

1. Craig making progress fixing issues & annotating non-issues
2. Would like to use @SuppressWarning(ErrorProne-specific warning name) but then Eclipse warns about unknown warning names... can we turn that off?

1. Markus idea: For warnings about intended reference equality, create something like Objects.areSame(a, b) → documents intent right in the condition, and we would need at most one warning suppression.
2. Andy idea: Put ErrorProne suppressions into comment lines; someone who cares can un-comment them; that will help document that something is fine and intended.
3. Fredrik: We should ask the ErrorProne developers for help.
4. Yoshito (update after meeting): We can change the warning level to ignore unknown token in @SuppressWarnings. I initially thought javac does not have such controll - but after the meeting, I confirmed this is not the case.

3. ErrorProne doc - For now, Eclipse users should use the Findbugs eclipse plugin instead, as it catches many of the same issues.
4. missing @Override - Craig to commit the fix for missing @Override today.

3. Review

1. Tickets in review state
2. Tickets with trunk changes / not under review

4. CLDR 30 integration status

1. Finished integration Sunday night (C and J)
2. May have a few minor updates, will plan to roll in by Monday night
3. few locale specific items

1. numbers
2. currency symbol

5. Build status

1. J coverage - com/ibm/icu/impl/coll/Collation#primaryFromLongPrimaryCE32:(I)J

1. Markus: I don’t see any relevant library or test code change that would have made this not-covered. There is a call site, so we can’t remove this method, but it won’t be easy to cover. Will get it added to the exclusion list. (I didn’t see it getting removed from the exclusion list either.)

6. Security (Steven)

1. https://sites.google.com/site/icusite/security
2. BRS (master & 58) - fill in fixed version in security page

7. BRS 58
8. Incoming

2016/09/14

1. Release status

1. Peter will start integrating CLDR data probably tonight or tomorrow

1. Target: before Wed next week
2. May need help from others e.g. on transforms; create shared doc with issues to get help. Steven can help with tool issues.
3. Reassign tickets for Michael?

2. Outstanding tickets

1. Markus still working on Greek uppercasing, then look at a few small bugs; otherwise punt
2. Peter has been able to do almost nothing this ICU cycle, sorry (CLDR, emoji, Apple work). Will plan to make a few easy fixes for crashes e.g. #12407

3. Urgent incoming bug from CLDR, ICU ticket #12730 “Exception when formatting compact currencies”, need fix to make CLDR charts

1. Note there are several open tickets about compact currency formatting; good chance this is a duplicate
2. Assigned to Andy for 58

4. CLDR ticket #9771 “collation index: add beyond-last-reordered-CJK index labels” and related ICU changes?

1. Markus: Old problem, and don’t have data to put there, should look at this for CLDR 31. Peter: OK, will assign the CLDR ticket accordingly - done.
2. CLDR moved this to 31 / not an urgent issue at this point

5. tzdata 2016g imminent (changes for Turkey, etc.) - Yoshito will take a look
6. VS2015 / win32 / Release - test failure #12705 (Steven)

1. uloc_tag.c, changed from /O2 to /Od (disable optimization) passed the test / not yet merged to trunk
2. (Debug passes, Release fails)
3. Steven will commit the fix (workaround) today

7. Spoof checker update is in. (andy, shane)
8. Withdraw - last week's discussion - Update to J DecimalFormatSymbols API change proposal (Yoshito)
9. BidiTransform will be in today

2. BRS 58

1. API promotion - target - next Wed for review

1. C - #12734 - Andy
2. J - #12735 - Yoshito

3. Incoming

2016/09/07

(Peter E will be out for this one)

1. Zibi [Mozilla]- MessageFormat 2.0 (icu-core mail) (Steven)

1. https://sourceforge.net/p/icu/mailman/message/35027629/
2. Markus at a glance:

1. Scope is much broader than MessageFormat
2. Two quoting/continuation syntaxes (pipe & double quote), unclear how they interact
3. Seems to allow text outside plural/gender selectors, like MessageFormat – this is hard on translators, recommend disallowing that; best to have whole sentences inside selected variants, no fixed pieces outside the selection. Some duplication of those “fixed pieces” is ok. (Translators don’t know how to move the boundaries.)
4. Didn’t see how nested gender/plural selections are handled; recommend not truly nesting, but making single, multi-value selectors, each with whole sentence. Keeping all of the related variants together has been a good way to get consistent translations.

3. Mark: Think about differences in data model between FLT & MessageFormat. There might be ways to extend the MessageFormat data model. Think of different ways of representing and compiling a “message”.

2. CLDR Internals slides: goo.gl/5EiIwG (Mark)

1. Goal is to make it easier for developers (not people) to on-board with CLDR — to help explain how it fits together. Main goal is not for consumers of CLDR (but some of the slides talk about that).
2. Would like more ideas for new slides. So far from CLDR meeting:

1. Slide for CLDR data to ICU - converter
2. Seed vs Main vs Exemplars
3. CldrFile filtering - provisional, unconfirmed, etc., picking “alt” values, merging files.
4. Parth to produce outline of problem areas for learning CLDR, since he did recently.
5. Explain George Bailey

3. Other feedback?

1. Locale data vs Supplemental data

3. IUC slides due!
4. Update to J DecimalFormatSymbols API change proposal (Yoshito)

1. setDigitStrings(String[] digits) to throw IAE when each digit cannot be represented by a single Unicode code point (for now) - C implementation currently only looks at the very first code point.
2. Agreed – document that the input is

1. Exactly 10 strings
2. Each contains exactly one code point.
3. Code points need not be adjacent.

5. Incoming
6. Build (Steven)

1. z/Linux online
2.  https://cldr-build.unicode.org/jenkins/ - please let Steven know if you don't have access and would like it

7. Collaboration (Steven)

1. slack? IRC? Hangouts? Others? Or just use the chat facility in the meeting minutes?
2. Topic specific chats/rooms? (Less random)
3. Perhaps as we get closer to release, real time collaboration might be useful.

8. Release Status

1. CLDR alpha soon
2. Sep 14 - feature freeze

2016/08/31

9. Zibi - MessageFormat 2.0 (icu-core mail) (Steven)
10. Remove icule (layout engine, not iculx=ParagraphLayout) from 58? (Steven)

1. deprecated since ICU 54, 2014 - http://site.icu-project.org/download/54
2. Ok with: Google, Apple, IBM
3. FYI: Oracle Java & OpenJDK have moved to HarfBuzz
4. Agreed - remove it from 58.

11. #10232 Cached decimal separator might not work (Yoshito)

1. DigitList::getDouble() depends on strtod to get double value, but strtod uses system locale
2. The current implementation detects decimal separator by sprintf(rep, "%+1.1f", 1.0), then check rep[2]. This value is set to gDecimal and cached permanently
3. When system decimal separator is changed, DigitList::getDouble() won't work.
4. Proposed solution - use strtod_l, which takes locale_t as an argument, not using system's global locale. - use "C" locale

1. newlocale, freelocale (these are included in the latest POSIX specification) and strtod_l  available on modern Linux, Mac OS X
2. Windows - _create_locale() / _free_locale() / _strtod_l
3. Others (?) - If a number represented by DigitList is not an integer number, ALWAYS detect system's decimal separator (20-30% slower than current)
4. Whitelist platforms via #ifdef, use configure script for others.

5. Agreed.

12. ICU 58 API proposal status

1. https://docs.google.com/document/d/1bRItQQkAxFvJj-wopQbpiPJ8ntin6FZDQfjekuwfEGM/edit#heading=h.2mu4bgjcen30 bidi

13. Incoming

2016/08/24

1. Reminder - Aug 31: feature freeze

1. Markus: Tight for me...
2. Agreed to push dates by two weeks, see top of this doc

2. Emoji properties [Mark]

1. We’re updating to Emoji v4.0. There are two closely connected issues: (a) the patch to StandardizedVariants for these, and (b) the future-proofing property ExtendedPictographic (formerly GAZ), for not breaking ZWJ sequences.
2. Patch: do we want to patch ICU for (a), or do we want to advise all users to patch their own copies? I’m inclined to say that we should patch (and document that we’re patching), to maintain consistency with the 4.0 ZWJ sequences.
3. ExtendedPictographic: do we want to incorporate this as a regular ICU property (not a UCD property, at least yet) or leave it as a hard-coded list? I’m inclined to think we could wait, but we should discuss.

1. Markus: No new property in ICU 58. Andy: Use as hard-coded set in rules.

4. Andy asks: Do the word break property values Emoji Base and Emoji Modifier need updating?
5. Future-proofing emoji ZWJ sequences Andy to 

1. Check for latest GB11′, WB3c′, LB8a′
2. Also fix segmentation properties that depend on the emoji properties.

1. Diff Emoji: v4.0 - v3.0: [\u2640\u2642\u2695]
2. Diff Emoji_Presentation: <none>
3. Diff Emoji_Modifier_Base: v4.0 - v3.0: [\U0001F3C2\U0001F3C7\U0001F3CC\U0001F46A-\U0001F46D\U0001F46F\U0001F574\U0001F6CC]

3. VS2015 update (Steven, Shawn)

1. http://bugs.icu-project.org/trac/build/testing-icu4c-win  - new buildbot in azure (Win 10, 64 bit), and IBM (Win 10, 32 bit - sysxp = Pentium D)

1. fine on non-win http://bugs.icu-project.org/trac/build/testing-icu4c

2. lab3 is not on vs2015 (yet?)
3. Passes on IBM internal build (different build system)
4. Steven’s recommendation: should be able to merge this shortly

1. - strange failure on sysxp which is a Pentium D running win 10
2. Passes in 32 bit build mode on a 64 bit CPU
3. Debug 32/64 bit builds crash in testing
4. merge from trunk to branch?

5. Steven/Shawn will merge the changes to trunk soon.

4. Build update - Steven

1. osuosl openpower access being setup as of yesterday .
2. more intel capacity is 'months' away- [Linux build bots?]

1. Possibly GCE? Azure?

3. https://cldr-build.unicode.org/jenkins/ - please let Steven know if you don't have access and would like it
4. old IBM Lab closure - thanksgiving-ish - should be able to get through ICU 58
5. Solaris

1. "swisdev" - build bots
2. (Pavel Heimlich) read only access w/o CLA? - Agreed to allow the person to access sensitive tickets and security scan result before CLA is signed.

5. ICU 58 API proposal status
6. Incoming

2016/08/17

1. Tweaking the ZWJ rules: https://goo.gl/cluFCn

1. hardcoded property - update character break : #12664
2. Andy has the implementation in branch - will merge the change for 58

2. Svn repository reorganization (andy)

1. Markus’s proposal – see the “Plan” section with what we agreed on
2. Proposed Svn directory structure after initial move
3. Keep initial move simple; move everything; defer additional clean-ups or adjustments until we are up and running with the new structure.
4. Should we rename the new icu/ directories to be icu4c?
5. Users move their own development branches if they want. For existing clients, use svn switch to move to new repository location.
6. Build System changes?
7. What else? Tools, scripts, public links, …

1. On web pages, keep old instructions (for working with maintenance branches), add new ones on top.

8. Make old directories read-only at some point?
9. Agreed to do this just after ICU 58.

3. FYI from Steven

1. git mirror (FYI, Steven, offline)

1. http://www.subgit.com granted a key for doing more transparent mirroring. Want to declare the git authors list  "good enough" to move forward on
2. Will refresh this after the svn reorg.

2. build farm

1. some bitten bots offline… will check tomorrow
2. lab closure: thanksgiving. ( should be able to complete 58 using current system)
3. machines wanted

1. And a network place to put them???

4. osuosl: intel/ppc systems should be up sometime soon

4. ICU 58 API proposal status
5. Visual Studio 2015?

1. Shawn to write a note to icu-core list - Steven will respond later.

6. Incoming

2016/08/10

1. Spoof/Confusables: (Shane/Mark/Andy)  Ticket #11800
   The Whole Script confusable test of a single identifier has proven to be not useful, due to a high failure rate on common words. The test checks whether a given identifier has any confusable that is wholly in a different script. Mark suggested deprecating the test. No uses of the feature were found in Google’s internal code or in public GitHub projects.
   
   Deprecating is awkward.
   
   The design of the ICU Spoof API uses a set of flags to control what checks are performed. The same Whole Script flag enables both the single identifier check (there exists some whole script confusable) and the two identifier check (these two ids are whole script confusable). The two identifier test remains useful.
   
   There is a constant, USPOOF_ALL_CHECKS, to enable all available checks. It includes the Whole Script check.
   
   We could do a behavioral change, to not perform the problematic single identifier whole script test.

1. Shane to write API proposal to explain -

1. may deprecate something?
2. explain the behavior changes expected with the internal change
3. impacts to existing users

2. Mark: The emoji v4.0 properties will be final in November, but many products will be implementing them ahead of time. Should we go ahead and implement the beta (public review) properties that we feel are solid? (All but perhaps the additional modifier bases?)

1. draft emoji v4.0 properties will be posted for public review today/tomorrow
2. Final approval in Nov UTC
3. Could take latest “best guess” into ICU 58 - agreed - http://bugs.icu-project.org/trac/ticket/12669
4. http://www.unicode.org/draft/Public/emoji/4.0/emoji-data.txt 

3. Tweaking the ZWJ rules: https://goo.gl/cluFCn - want to have Mark to discuss this - moved to next week.
4. Incoming

2016/08/03

UTC - Mark, Peter and Steven

1. Feature Freeze - Aug 31?

1. No API changes beyond this point
2. Final check in 1 week after?

2. Ancient bugs regarding locale aliases (eg. iw/he): [Fredrik]

1. http://bugs.icu-project.org/trac/ticket/8392
2. http://bugs.icu-project.org/trac/ticket/9208
3. http://bugs.icu-project.org/trac/ticket/9223

Fredrik will look into these and propose something

3. Incoming

2016/07/27

1. C++11 on AIX etc. (XL C/C++ compiler for IBM big-endian platforms)

1. This compiler still only supports parts of C++11
2. Experiments show that Unicode string literals and char16_t work
3. Andy: Worth switching just for that
4. Markus: ... and experiment with the rest
5. Do change configure scripts to set C++11 as the compiler option, so that we can start using the supported features. Ticket #12643

2. Calendar field overflow

1. cal.set(HOUR, 1000) -> 1000*60*60*1000 = 3,600,000,000 (> 2,147,483,647)

1. int computeMillisInDay()
2. int computeZoneOffset(long millis, int millisInDay)

2. Markus:

1. Move the real implementation into a new long version.
2. The new methods could be @internal if we don't actually want these to be public. We may make it private, not even protected
3. In the base class, make the int version call the long version. Not that simple, because the method's return type need to be long. And for full compatibility, base class implementation must call int version..
4. Other call sites: If the value fits into int, call the int version, otherwise call the long version. At this moment, these methods which causes int overflow are called from the base calendar class only.

3. Concensus - do not introduce breaking change...

3. CLDR/ICU joint call?
4. Incoming

2016/07/20

1. Require certain C++11 features in ICU 58 (Andy & Markus)

1. http://en.cppreference.com/w/cpp/compiler_support
2. See Andy’s email, even HP aCC supports all of the following since version A.06.28 (2014-mar)

1. Unicode string literals & types
2. “constexpr”
3. Defaulted and deleted functions
4. “explicit”
5. Initializer lists
6. “auto”
7. “nullptr”
8. “static_assert”
9. Range-for loop
10. Dynamic initialization and destruction with concurrency (magic statics)
11. “noexcept”

3. Maybe say that every C++11 feature is ok if every compiler except for “Digital Mars C++” (former Zortech C++/Symantec C++) supports it?

1. Consensus for ICU implementation code.
2. No consensus yet for requiring C++11 in public headers/for clients. Will ask around.
3. TODO(Andy & Markus): Announce to icu-support & icu-design
4. TODO(srl): Forward inside IBM
5. If some build bots cannot be updated to C++11, then abandon them.

4. FYI: Jeff found for Visual Studio that WCHAR/char16_t and L””/u”” are interchangeable without casting.

2. ICU: combine icu, icu4j, tools, ... into one trunk (Markus)

1. See section “Plan” from agreement June 1.
2. Had email discussion this week.
3. Still ok to proceed? – confirmed

3. ICU 58 API proposal status

1.  ICU4C API: promote FieldPosition::DONT_CARE to stable. (andy)

4. Build system status

1. https://cldr-build.unicode.org/jenkins/ (requires login)
2. Jenkins can be used for a new ICU build system
3. Build servers can be added by others, need not be co-located
4. Protocol:

1. Jenkins can ssh into a server and issue commands
2. JNLP via browser
3. Script with commands

5. TODO(srl): ICU-specific instructions for setup, what to install, how to register a build server

5. Incoming

2016/07/13

1. Minimum MSVC version for 58.1

1. As minimum compiler level / C99 features: IBM - confirmation needed.

1. IBM is OK.

2. OSUOSL and build

1. OSUOSL

1. Request to use their resource for ICU project was accepted
2. Intel and Power systems should be available

2. Azure Windows VM setup (thanks!)

3. Platforms in concern

1. HP-UX

1. The compiler may not support later C/C++ standards

2. Solaris
3. AIX
4. Can we go up to C++11 on platforms we need to support? Via gcc or clang if not the “native” compiler?
5. HP-UX would be the only platform not supporting latest standards – IBM team is also considering to stop supporting it..

4. Question regarding codepage data: Does this come from CLDR at all? (seem not, just exists in ICU). [Jeff]

1. ibm-* tables came from IBM Toronto [CDRA], converted into *.ucm format by ICU team.
2. Others were gleaned from respective OSes via programs exercising their conversion APIs. (This was done mostly in 2000-2001.) Reason: Published tables were often incomplete (e.g., showed only round-trip conversions, no fallbacks) and/or not machine-readable.
3. A few were based on certain standards, such as GB 18030.
4. Plus occasional bug fixes.
5. See also http://site.icu-project.org/charts/charset

5. Incoming

2016/07/06

1. icu-project.org admin (Markus, Michael)

2. Minimum MSVC version for 58.1

1. Apple? IBM? ..
2. Already agreed to bump project files to 2015 (Shawn)
3. Q is minimum of what we can require the compiler to be

1. C99?  2015 for some things
2. 2015 added support for Unicode string literals & char16_t
3. https://msdn.microsoft.com/en-us/library/hh567368.aspx
4. https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md “As of March 11, 2016 Chromium requires Visual Studio 2015 to build.”
5. IBM to confirm by next week

3. TZ data updates - stop publishing updates for older ICU versions?

1. http://source.icu-project.org/repos/icu/data/trunk/tzdata/icunew/2016f/

1. 5 versions

1. 36 or older : zoneinfo (32bit) only
2. 38 : zoneinfo (32bit) + metazoneInfo (metazone mapping) + supplementalData (zone-region mapping) + windowsZones
3. 40: same as 38, but other parts of supplementalData are different from 38
4. 42: same as 38, …
5. 44 or newer: zoneinfo64 + metaZones + timezoneTypes + windowsZones

2. Not tested for these variations..
3. 3.6: Sep 2006 / 3.8: Sep 2007 / 4.0: Jul 2008 / 4.2: May 2009 / 4.4: Mar 2010
4. Agreed - drop 4.2 or older files

4. Unicode copyright year?

1. // © 2016 and later: Unicode, Inc. and others.
2. Should we use the year when the new source file is added? In other words, if we add a new source file in year 2017, should it be “// © 2017 and later: Unicode, Inc. and others.”?

1. Yes
2. Do not update the year in older files. No explicit year range.

3. Generated files, like API change report, it would make sense to just have the year. I just ran into this (andy). Perhaps change scanner to accept just the year.

1. Can generate as ©2016-{current}   (Steven)
2. Markus: We should use the agreed copyright lines. No need for {current}. Just generate each file with its appropriate first-in-Unicode year.
3. #define U_COPYRIGHT_STRING → “© 2016 and later: Unicode, Inc. and others. © 1997-2016 International Business Machines Corporation and others. All Rights Reserved.” (and don’t ever change the Unicode year from 2016) (Steven’s proposal?)
4. Files generated from CLDR: Probably ok to only have Unicode copyright (always 2016 and later), drop IBM copyright.

1. (Otherwise we would have to track which file was first created when.)

5. Otherwise try to retain copyright headers that are now there. Usually needs a static string per file.

5. Add JUnit binaries to the svn ignore list?

1. lib/JUnitParams-1.0.5.jar
2. lib/JUnitParams-1.0.5-javadoc.jar
3. lib/JUnitParams-1.0.5-sources.jar
4. lib/hamcrest-core-1.3.jar
5. lib/junit-4.12.jar
6. lib/junit-4.12-javadoc.jar
7. lib/junit-4.12-sources.jar
8. Yoshito will add lib/*.jar in svn ignore list (will file a ticket)

6. ICU 58 API proposal status
7. Incoming

2016/06/29

1. 58m1

1. Trunk changes / not under review
2. Code review (past due)
3. BRS

1. ICU4J JaCoCo coverage target  was not migrated to JUnit - updated yesterday. There are many coverage differences since JUnit migration
2. ICU4J clover coverage target is not yet migrated to JUnit - we use JaCoCo these days - propose to deprecate (#12612)

2. Build System

1. Test machine for ICU4J running with JUnit 4.10 and a modified JUnitParams

3. CLDR status
4. ICU 58 API proposal status
5. Incoming

2016/06/22

1. Michael

1. Last day @ IBM - July 7
2. Administrative tasks

1. Icu-project.org - all remote

1. Short short term - Steven to fill in
2. Svn
3. ICU trac
4. Help with admin?  — 

1. Peter - will check with management
2. Ron - (will manage on Microsoft side)
3. After july 4th - will check with Markus

3. Thanks

2. Build System (Steven)

1. Current:

1. Public facing - bugs.icu-procect.org/trac/build

1. Build servers -- all IBM, mostly internal
2. IBM HW lab going away Jan 2017

2. IBM internal - build system,

1. Ibm internal server, ibm internal buildbots
2. • actual ICU4C releases happen here •
3. (ICU4J releases happen at Yoshito’s house)

3. No visibility for debug, restarting, etc…
4. No way for anyone to ‘build on demand’ - besides IBM internal system

2. Proposal

1. Jenkins - build server “cldr-build” - hosted by Microsoft Azure

1. Builds on demand… specific branches… 
2. Release process could happen here — 
3. Actual build hardware:

1. Could use current IBM h/w for now
2. Could use any cloud resources
3. Unicode (fast) mac
4. http://osuosl.org - public access hardware (IBM power, intel linux)

1. Ron has contact

5. Windows VMs on Azure

4. Distributed admin -
5. Can post status to trac

1. Timeline
2. Can post on tickets w/ pass/fail status (i think)

6. Security - need to monitor carefully
7. Timeline?

1. Switch over post 58?

2. Next step - Steven to create a Google doc to discuss.

3. Unicode transition -  list of tasks

1. ICU license file - LICENSE

1. move the very first section - “ICU License - ICU 1.8.1 and later” to the very end, next to Third-Party Software License section.
2. Remove “1. Unicode Data Files and Software” license from “Third-Party Software License” section
3. Insert the latest Unicode Data Files and Software license to the beginning of the file

4. ICU 58m1

1. Tag only
2. J copyright - Michael plan to do this by the end of this week
3. CLDR import - peter to take a look, do by eod June 28 (trunk, not new ST data)
4. Schedule

1. Regular feature/bug fix work check-ins by June 24 (Fri)
2. Code review done by - June 28 (Tue)
3. Last check in - June 30 (Thu)
4. Tag M1 - July 1 (Fri)

5. BRS

5. Build Status

1. ICU4C trunk build on Linux system?

1. Michael to take a look - ../../test/testdata/testtypes.txt:38: couldn't open input file riwords.txt

1. Needs an odd number of BOMs
2. May be good to have a buildbot with euc-jp or something as default codepage?

2. ICU4C trunk memory leak

1. CalendarData and some others - andy to look into this

3. ICU4J trunk coverage - has been failing because of private enum coverage

1. Yoshito has a ticket to exclude these enum / constructor of static method only class from coverage check, but not yet done - for M1, I’ll update the exception list to include these ‘known’ code not included in coverage

6. ICU 58 API proposal status
7. Eric Mader @ server?

1. Needs CLA signed

8. Incoming

2016/06/15

1. Unicode transition -  list of tasks
2. Tzdata2016e

1. Committed to data/icu4c/icu4j under #12415
2. No metazone mapping update by 2016e
3. #12592 tz2icu.cpp imposes a limit of 2050 on timezone transitions

3. JUnit - Stuart’s doc

1. Eclipse dev env setup (current, might be updated later) - short summary below:

1. Run “ant init”
2. Import “external-libraries” project under <icu4j-root>/lib in addition to ICU4J library/test projects
3. “Icu4j-testall” project is no longer available

2. A few issues that should be fixed soon

1. “ant check” still returns BUILD SUCCESS even some tests are failing (transliterator test case is failing in trunk at this moment)
2. Logln is disabled. It’s difficult to debug test failure.

4. ICU 58 API proposal status
5. Plan/schedule for updating to Visual Studio 2015?

1. File a new ticket
2. Create SVN branch / make the change there
3. Merge them to trunk once we confirm it does not break anything.
4. Use of “Universal API” [sp?] - Shawn

1. Currently Subprojects w/ build
2. Steven - enumerate different configurations?  Shawn - that was tricky…
3. * this will be a separate ticket

6. Ratio symbol (x0∶x0)  (U+2236) vs. ASCII colon (U+003A) (x0:x0)  for time formats?

1. 1∶20 vs 1:20

1. Visual distinction - baseline, etc

2. CLDR?

1. Ron to file ticket? Please mention CLDR ticket 5877

3. Add to Equivalence group?

1. http://unicode.org/cldr/trac/ticket/5877 - “data for parsing equivalency”

4. Vs minus sign - ASCII preferred
5. Status of CLDR time-separator symbol - http://unicode.org/cldr/trac/ticket/9411 etc

7. 58M1

1. July 1 ( Friday before US July 4th Holiday)
2. Will start BRS on June 22 (next Wed)
3. Tag-only release

8. Incoming

2016/06/08

(Peter E away for this meeting)

1. Unicode transition -  list of tasks

1. ICU4C copyright comment
2. Ready to work on ICU4J copyright comment at this point? Yes -> michael
3. Committer spreadsheet https://docs.google.com/spreadsheets/d/1XM1gO5ZwKhODHuxEWVkvqHggYKfuOLJbg98vT5zEEMg/edit#gid=0 

1. Can compare https://github.com/icu-project/icu-git/blob/master/scripts/authors.txt 

4. Steven will lock SVN accounts not covered by Unicode CLA - on Thu/Fri
5. Reminder - Git public email address - please put your own email in https://docs.google.com/spreadsheets/d/1MJUcNha_WHn7MUlrUlgnvreMp5D3YdQZo998XNuvKgo/edit#gid=1311777886 if it’s OK to use it for git mirrors.
6. CLA assistant - https://cla-assistant.io/icu-project/icu4c - or https://goo.gl/zWGZtD
7. Lawyer suggested this text for Trac:

1. Please do not submit code or data without first agreeing to the terms and conditions at [link] and [emailing a digital copy to email alias or going through eventual e-signing flow].

8. Steven draft:
   Please sign the Unicode CLA for your patch: Either (1) sign at  https://cla-assistant.io/icu-project/icu4c and give us your GitHub ID here or (2)  follow the instructions at https://goo.gl/zWGZtD and note when you have sent in the scanned CLA. Unicode License: http://www.unicode.org/copyright.html#License 
9. Markus merging the two above:
   Please do not submit code or data without first agreeing to the terms and conditions in the Unicode License: http://www.unicode.org/copyright.html#License and either (1) signing at  https://cla-assistant.io/icu-project/icu4c with your GitHub ID (note your ID here) or (2) following the instructions at the bottom of https://goo.gl/zWGZtD and note in this ticket when you have sent in the scanned CLA.  ( Done )

2. JUnit, see Stuart’s doc

1. Merged into trunk, immediate issues getting resolved, more tasks TBD

3. Incoming

2016/06/01

4. ICU: combine icu, icu4j, tools, ... into one trunk (Markus)

1. related/FYI: Git mirror updated- now has releases (tags)… possible successful ‘update’ (moving the mirror forward without restarting from scratch)

1. https://github.com/icu-project/icu4c 
2. https://github.com/icu-project/icu4j 

5. Unicode transition -  list of tasks

1. ICU4C copyright comments - #12564, reverted once / Once Michael is back from vacation, do it again (prepending Unicode copyright, instead of replacing - also clean up trailing white space chars)
2. Need to get CLA/Trac site going. Tagging tickets with keyword ‘cla’ for now.

6. API proposals (design list mails not going through)

1. Yoshito has a proposal for ICU4J DecimalSymbols strings, Peter to review for next week

7. Incoming

1. Peter to investigate and comment #12530 (should currency be included?)

8. JUnit (Stuart)

1. http://bugs.icu-project.org/trac/ticket/10152 
2. Not yet merged? - hope to finish today.
3. Changing as little as possible
4. Todo: guides of how to write new tests
5. Want to test with JUnit 4.10 also… need to get Ivy to not update -  Yoshito - maybe just allowing the build script to override IVY_HOME

2016/05/25

Googlers unable to attend

1. Scott’s goodbye
2. Unicode transition -  list of tasks

1. Committers Spreadsheet: https://docs.google.com/spreadsheets/d/1XM1gO5ZwKhODHuxEWVkvqHggYKfuOLJbg98vT5zEEMg/edit#gid=0  - sent out to icu-core
2. (new task: remove anyone not on this list from ‘src’ group.)

3. J ‘char’ symbols to String

1. Decimal digit, separators, plus/minus, percent
2. Compatibility issue

1. Need to keep getter returning char - getPercent()
2. If not char -

1. Throwing UnsupportedOperationException ?
2. Default symbol - e.g. ‘%’ for Percent, ‘+’ for plus, ‘-’ for minus?

1. Special case: If it’s just char + bidi marks, then strip off the marks

4. Incoming
5. Check in process (Shawn)

1. http://site.icu-project.org/processes 
2. http://site.icu-project.org/processes/ticket-lifecycle 
3. http://site.icu-project.org/repository/tips#TOC-Merging-and-Branching 

1. For non-trivial commits, better to use a feature branch

4. ticket:####: <description>
   < can be multiple lines…>
   
5. Added some comment on branching: https://sites.google.com/site/icusite/processes/ticket-lifecycle?pli=1#TOC-Coding (Steven)

2016/05/18

1. ICU/Unicode (w/ Rick)

1. Finalized wording of announcement - after this meeting, will be posted to Unicode blog / sending out announcement by Rick, along with

1. Unicode copyright page
2. CLA form

2. Review the list of tasks for transfer. - announce today ~2pm pacific time

1. Update to the “News” part at the top of icu-project.org (Steven)

1. 2016-05-18: The Unicode® Consortium has announced that it will host development of the ICU libraries. The ICU Project Management Committee is now a Unicode Technical Committee, the ICU-TC. ICU will continue to be released under a similar open source license. For more details, see the Unicode announcement.
2. In draft, ready to post.

2. JUnit for ICU4J

1. list of open items

1. which need done before integration and which can be tasks for afterwards?

2. needed to modify JUnitParams to run on JUnit 4.10

1. where should the project for the modified JUnitParams live?

3. Target: June 1
4. Start continuous build with the branch

3. Incoming

1. Peter to investigate and comment #12530 (should currency be included?)

2016/05/11

1. UTC meeting; people who cannot call into ICU meeting as a result: Peter, Steven?, Mark?
2. J Coverage check - latest

1. Exclude compiler generated code

1. Enum - valueOf/values

1. Markus (ideas copied from email discussion): Hm, compiler-auto-provided methods...
2. These are private enums, so unreachable.
3. We could make them reachable just to call implicit methods for coverage. This seems bad.
4. We could cover them by adding a test-only method to the public outer class, only to call the private methods for coverage. This seems bad too. I don't want more @internal members of public classes if we can help it.
5. We could cover them by using reflection to circumvent their private-ness, as suggested for constructors on http://site.icu-project.org/processes/coverage Advantage: They would actually be covered, without adding weird stuff to the class.
6. We could add them to the exclusion list. Easy but feels a little like cheating.

2. Constructor of static utility class
3. Yoshito will try to detect such cases and exclude them via tool code

3. JUnit migration

1. Stuart, Markus and Yoshito will discuss compatibility issues / migration issues in a separate meeting scheduled this week or next week.

4. Incoming

2016/05/04

1. ICU/Unicode

1. We have list of tasks for transfer. See ICU Project > ICU-TC.

2. Caching issue

1. Mark: Guava has a lot of very well-tested and high-performance caching libraries (as well as a lot of other useful stuff). Might be time to use it.

1. License? [Apache] Jar vs. source? Limited to Java 6?
2. Not adding Guava dependency now.

2. Use of SoftReference for cache

1. http://developer.android.com/reference/java/lang/ref/SoftReference.html - Avoid Soft References for Caching

3. Strategy for clearing SoftRefefence in hotspot [http://jeremymanson.blogspot.com/2009/07/how-hotspot-decides-to-clear_07.html]
4. ICU4J to use SoftCache by default, but allow user to replace cache implementation if necessary?

1. E.g. com.ibm.icu.text.DateFormat.CACHE = com.acme.ICUCustomCacheImpl in ICUConfig.properties
2. At runtime, reflection to resolve cache implementation class, but if it’s not available, fallback to the stock ICU implementation

5. Markus: Short-term, switch some uses of SimpleCache (SoftRef to Map of direct values) to SoftCache (direct Map to SoftRef values) - Agreed

3. ICU4J Test breakage

1. http://bugs.icu-project.org/trac/ticket/12513
2. Markus will work on this with Yoshito, Mark

4. Minimum Windows version support in ICU 58

1. Apple: only needs to support Win 7 (server 2008) and later
2. QT: already dropped XP and Vista before previous LTS
3. Mozilla: would like to stop supporting XP
4. Consensus. - drop XP (no mention of Vista) -

1. From: srl
   Thank you Jonathan, John, and Roger for replying.
   
   The ICU PMC has discussed this, taking into account your replies.
   At this point we are planning to drop support for Windows XP in ICU 58.
   
   Regards,
   Steven for the ICU PMC

5. Incoming

2016/04/27

1. ICU/Unicode

1. All attorneys from 4 companies (Apple, Google, Microsoft and IBM) and developers agreed on the Unicode CLA proposal

1. No distinction between one time and on-going contribution.
2. Once a company signs the CLA, no need to add a new developer’s name in future.
3. Heads up - We cannot accept a patch from posted in an ICU ticket unless the author already signed the CLA.

1. We plan to add a warning note in ICU trac form - a patch from someone who does not have a CLA signed cannot be accepted/must be ignored.
2. But that does not mean we cannot fix the bug even if the submitter does not sign the CLA, right? We just have to come up with our own fix.

4. CLA digital signature service

1. Example:- https://www.elastic.co/contributor-agreement/  - seems to use Adobe Sign https://acrobat.adobe.com/us/en/sign.html 
2. Example: Google Closure project: https://github.com/google/closure-library/pull/641

5. Action items:

1. Warning text in ticket / link to CLA form
2. Searchable CLA signee list maintained somewhere
3. Electronic sign / online CLA form (long term)

2. Next actions

1. All 4 companies to sign the new CLA for future contributions
2. IBM to send the letter to Unicode consortium / announcement

2. ICU 58 API proposal status
3. Incoming

2016/04/20

4. ICU/Unicode

1. A meeting for resolving remaining issues in the proposed Unicode CLA by attorneys and developers from 4 companies is scheduled tomorrow - 3pm ET/12pm PT tomorrow (ICU conf#)

5. 58 schedule

1. CLDR

1. Release 30: Sep 15 [http://cldr.unicode.org/index#TOC-General-Schedule-]
2. CLDR does not try to align milestones on Wednesday
3. Schedule may become less of a specific commitment

2. Should we come up with ‘general schedule’ like CLDR? E.g. Agreed

1. ICU Fall release

1. Release: Oct 1
2. RC: Sep 15
3. Feature Freeze: Sep 1
4. Milestone: Jul 1

2. ICU Spring release

1. Release: Apr 1
2. RC: Mar 15
3. Feature Freeze: Mar 1
4. Milestone: Jan 15

6. RuleBasedBreakIterator, confirm that we really want to make it final. Mail on design list. #12071 (andy)

1. Agreed not to make it final.

7. Downlevel Windows support.  Can we move to Win7? (ron)

1. Win 7 as min supported version is OK with Apple
2. Action - follow up the message thread with Mozilla guys, explaining the adavantage of newer Windows platforms  (non-LCID based locale support) - no support for Windows XP / 2003 server or older Windows revisions.
3. Ticket to update the ICU LCID list.

8. ICU 58 API proposal status
9. Incoming

2016/04/13

1. utrans_openU performance, more details in #12380-comment:3 [Peter]

1. uhash/Hashtable enhancements

1. Any objection to adding uhash_initSize and Hashtable constructor  that takes initial size? Agreed.
2. Any objection to allowing smaller minimum sizes (e.g. 7 instead of 13)? No objections - need a little bit more investigation
3. Markus: There might be other possibilities, too. Maybe make a single hashtable with concatenated keys (with a separator)? Maybe try to not store any UVectors if there are only 1 or 2 items? For Maps with very few keys, maybe use a simpler structure with linear search? If we know the exact size of the table, then maybe make a hash table or other Map of exactly that size? Rather than use a bit map, use an array of 16-bit ints, with the length at index 0; or an index into a UnicodeString that stores all of them.

2. Can we limit the number of supported variants (currently 11)? Enables use of bitmaps.

1. Mark: We could allow 32 for now, and pump it up if the number from CLDR gets over say 16. (If we go for a flat list, we don’t need this limitation.)
2. Markus: The limit can be in the thousands if we store short lists of small integers.

3. Can reduce registry memory allocation by 65% with minor changes
4. Investigation using MallocStackLogging & malloc_history
5. Hash table mapping script codes to something → change to use a simple array
6. Nuke the specDAG registry, get info from the main registry

2. ICU 58 API proposal status

1. Mark: comments on BIDI:

1. Use standard terms from the BIDI algorithm; “Arabic-European numerals” don’t make sense.
2. Descriptions like “Constant indicating Arabic letters are in shaped form” are also strange. It appears that these are actually goals. That is, Arabic letters are to be transformed to shaped form. But I’m guessing.

3. Remove ICU4J ‘old’ module build targets?

1. ICU User guide: Packaging ICU4J
2. Yoshito to send proposal to icu-design about removing module build & test targets

4. ICU licence, letter, CLA progress

1. Markus will propose a modified CLA, incorporating discussion since the current draft was circulated.

1. To be reviewed by contributor counsel
2. Then to be sent to Unicode counsel

2. PR - proposal sent by Steven to Mark (Mark: my phone cut out)

5. Current CLA

1. Microsoft signed last week - ssh / icu-core added
2. Q: apple ongoing CLA? http://bugs.icu-project.org/trac/browser/icuhtml/trunk/legal
3. http://source.icu-project.org/repos/icu/icuhtml/trunk/legal/contributions/
4. Example, consolidated list of Google Authors

6. Incoming

Example of module build

        <target name="breakIterator" depends="_copyFullPropsData" description="Modular build of break iterator services">

                <mkdir dir="${module.bin.dir}"/>

                    <javac srcdir="${icu4j.core.dir}/src"

                                        destdir="${module.bin.dir}"

                                        source="${javac.source}"

                                        target="${javac.target}"

                                        encoding="${java.src.encoding}"

                                        debug="on" deprecation="off">

                            <include name="com/ibm/icu/impl/UCharacterName.java"/>

                            <include name="com/ibm/icu/impl/data/*Break*.java"/>

                            <include name="com/ibm/icu/lang/**/*.java"/>

                            <include name="com/ibm/icu/text/*BreakIterator*.java"/>

                            <include name="com/ibm/icu/text/UnicodeSetIterator.java"/>

                    </javac>

        </target>

// For building icu4j.jar including BreakIterator class and its dependencies

$ ant breakIterator moduleJar

// Testing BreakIterator functions with the module (subset) jar

$ ant breakIteratorTests moduleCheck

2016/04/06

1. utrans_openU performance, more details in #12380-comment:2 [Peter]

1. Discussion. Code has not seen much development or optimization in a long time.
2. Peter to investigate further.

2. ICU/Unicode progress

1. Letter is ready for review by Mark/Unicode

1. Steven will send other updates along with the letter.

2. CLA - expected minor updates
3. The Unicode license is not exactly the same as the MIT license
4. Steven is working on ‘wording’ for publicity
5. When/Who work on copyright updates?

1. After letter is accepted / CLA signed

3. ICU 58 Schedule - any inputs?

1. Expected end of Sep / beginning of Oct
2. Google does not need to push the schedule earlier any more
3. Microsoft is fine with the schedule
4. Apple - fall release has no schedule impacts
5. Tentative release date: Sep 28
6. ICU 58 milestone

1. Tag only?

4. CompactDecimalFormat (Java)

1. Negative numbers - throwing UnsupportedOperationException #12447
2. Arabic locale - stop working #12449
3. Fomat - thread safety issue
4. Stuart to take a look to find out what to do.

5. Incoming

1. Locale bugs -> tickets are gathered in a Google Doc - ICU Locale Issues

2016/03/30

1. Microsoft

1. Welcome: Ron Ruzicka, Axel Andrejs

2. ICU 57

1. BRS (post-release check & cleanup)
2. Difference between data generated from CLDR tag icu-57-1 and data that is in ICU 57.1, in the locale validity stuff. Andy filed #12442 to investigate this.

3. ICU4J test coverage (Markus)

1. Short-term: Working on recent tickets with "coverage" keyword

1. branch for now, want to merge into trunk

2. Longer-term: Want every ICU4J library code method covered. Add tests, or remove from library, etc.
3. See email “ICU4J method coverage” from Yoshito mar17 about ant coverageJaCoCo failing with not-covered methods.

1. (Yoshito) We may add ‘exception’ to let the coverage check pass - so we can detect new code without test coverage.
2. Priority on public not-deprecated methods and their direct implementation/override methods
3. Next: Implementation methods called by those
4. Last: Deprecated methods

4. Easy: Download the report_html.zip from the "ICU4J trunk coverage" build bot, unzip, and open its index.html file. Look for the Total Missed Methods.

1. Like Yoshito did: http://icu-project.org/~yoshito/jacoco_57.1/#dn-j shows 11% of methods not covered: 1,116 out of 9,929

5. Q: JaCoCo reports non-existent constructors in static-only classes as not covered. What to do? (e.g., CollationLoader.ASCII) Test via reflection? 

4. IUC 40 abstracts due apr04 (see also IUC 40 section above): ICUers IUC 40 doc
5. ICU at Unicode: Summary of CLA changes/discussion

1. IBM to Unicode letter - should be finalized soon (IBM giving feedback)

1. Changes to license needs to be resolved

2. CLA - Lawyers to discuss

6. JUnit jars: in repository, or use ivy? For ivy, puts its jar into repository? (Stuart)

1. Yoshito: Suggested changes automatically bring down ivy.

7. FYI: https://www.youtube.com/watch?v=CfZE56E0Uts
9. Incoming (48 bugs, please reserve some time to look at)

2016/03/23

1. Remaining ICU 57 release items?

1. BRS

1. Tags in CLDR: http://unicode.org/cldr/trac/browser/tags/

1. icu-#-#-# ( Other forms: tag-for-icu4j-#, icu#milestone, icu#_###)

1. icu-57-1

2. Tags are only there for exceptions. CLDR GA tag is normally used for ICU
3. moving LDML2ICU out of CLDR could help, but is problematic due to dependency on CLDR code

2. Announcement
3. Download page - change from candidate
4. Pending user guide updates

1. #12417
2. Others?

2. ICU4J API coverage strategy (Yoshito)

1. ICU 57.1 coverage: http://icu-project.org/~yoshito/jacoco_57.1/
2. Missed method counts

1. com.ibm.icu.charset: 12
2. com.ibm.icu.lang: 23
3. com.ibm.icu.text: 440
4. com.ibm.icu.util: 97
5. We probably need 100% ICU4J method coverage, including impl classes/methods.
6. Add coverage tests, or remove from library, etc.

3. ICU at Unicode: Summary of CLA changes/discussion 

1. IBM legal waiting for Unicode approval of assignment letter, but that is blocked on agreement on Unicode license
2. Steven/Yoshito set up a call inviting lawyers from 3 companies - conclude license term / CLA this week (hopefully)
3. Write and run script to change copyrights
4. Prepare announcement text for Unicode, IBM (Steven)

4. Onboarding new contributors (Steven)

1. Easiest to have full participation after transfer to Unicode.
2. Ok to invite future contributors to weekly meetings ahead of CLA
3. First step

1. Invite MS folks to this call (done)
2. Set up access to this agenda doc (it’s public- can add people for edit as needed)

5. Incoming (currently 39, please reserve some time to go through)

2016/03/16

1. ICU 57

1. Proposed fixes before 57 GA

1. #12372 new MeasureFormat fails for nb, sv (and nn) → Peter DONE, Markus review

1. CLDR#9324 durationUnit alt values cause bad LDML2ICUConverter output - will be done after CLDR release 29 tag, but will be merged into CLDR 29 maintenance branch
2. Will change ICU data, and then CLDR will be changed to output equivalent data.

2. #12373 $GAZ definition rather wrong in char.txt → Andy DONE, Peter review DONE
3. #12380 Big performance regression opening transforms in ICU57rc

1. No fix for 57
2. Peter: Add a note in 57 download page DONE

4. #11962 ICU time zone data updates - ICU 57 → Yoshito\

1. Tzdata2016b DONE
2. maybe tzdata2016c is coming soon

2. BRS
3. 57 download page

2. ICU / Unicode

1. Lawyers are discussing... 
2. Steven to check the latest status / what’s next.

3. ICU4J API coverage from test suite

1. Do we have a page with instructions?
2. Clover?
3. "ICU4J trunk coverage" build bot – parse generated report.xml or report_html.zip file, compare with the ICU API signature file? (API signature files are at icu4j/trunk/tools/build – files like icu4j57.api3.gz)

4. Incoming

2016/03/09

1. ICU 57 RC

1. ICU4J tagged, binaries uploaded
2. ICU4C will be tagged soon.
3. Reviews
4. BRS
5. 57 download page
6. Known issues

1. ICU4J CollationKey breakage on IBM Java 8 (actually, reproduced with 53.1 and newer)

2. Incoming

2016/03/02

1. ICU 57

1. coming milestone dates:

1. 2016-03-04 (Fri): Final check-in (response to code review, except some BRS items); final CLDR integration done
2. 2016-03-09 (Wed): ICU 57 RC

2. Reviews
3. Tickets with code changes, not in review state
4. ICU4C test failures? - build status

1. mac build issue -> environment problem? Mac/ibm-moonlight
2. memory leak -> Michael is working on this, Markus still reviewing kazède’s DTPG changes

5. BRS
6. Heads-up: break iterator data size growth for Emoji (andy) from 4.07 MB to 4.4 MB for all. Individual Line Break data files go from 120k to 156k. Similar across all seven tailorings. Also, Finnish LB tailorings problematic, but not a new problem.
7. Build failure on Macs

#ifndef __has_cpp_attribute         // Optional of course.
 #define __has_cpp_attribute(x) 0  // Compatibility with non-clang compilers.
#endif
(this was done, see platform.h line 435)

see http://clang.llvm.org/docs/LanguageExtensions.html 

→ Peter/Andy/Markus/Michael to figure out – done

2. API status promotion for 57

1. ICU4C
2. ICU4J
3. time separator APIs marked as @internal, don’t clobber in branch integration
4. agreed.

3. BRS additions proposed (Markus)

1. switch-case fall-through: check that all intended fall-throughs are annotated, see http://bugs.icu-project.org/trac/ticket/12166

1. Mark suggests adding this to the build bot configurations - covered by (ii) below
2. Andy suggests having the configure script add this automatically for clang - agreed - http://bugs.icu-project.org/trac/ticket/12330 (no need to add to BRS)
3. exclude the layout engine code & tests

2. every header file should include all other headers if it depends on definitions from them; check internal header files: http://bugs.icu-project.org/trac/ticket/12141 - agreed – added to BRS (template & 57)

4. More day period nonsense: (kazède)

1. what to do with “midnight = 0:00”

1. For now in ICU 57, suppress output of “0:00 midnight”, fall back to 0:00 am or 0:00 at night etc.

1. Consensus

2. kazède to submit CLDR ticket about this.
3. Mark suggests possible future ICU API to request midnight yes/no – Mark to submit ICU ticket.

2. day period on its own point to the center of that period, but which day?

1. example: in en, NIGHT1 is [21:00, 6:00), so midpoint is 1:30am. Should “Nov 13 at night” parse to 1:30am on Nov 13 or 14?

3. should “am” and “pm” parse to 6am / 6pm respectively on its own, when no hour is provided, like flexible day periods do?

1. kazède to submit CLDR ticket about b & c.

5. ICU/Unicode status (Steven)

1. Legal review in progress…

6. spam (Steven)

1. Any volunteers to update http://bugs.icu-project.org/trac/wiki/BadContent ?
2. API-based services are being used as of today - http://stopforumspam.com and http://botscout.com
3. (Defensio went down, and BlogSpam changed their API format)
4. All inbound spam deleted (thanks to whomever helped)

7. Review Unicode break tests
8. Incoming (28 non-spam bugs, 78 spam bugs)

2016/02/24

1. Reminder: 2016-02-28 (Sun): Final check-in for features/regular bug fixes (Feature Freeze)
2. Emoji break iteration, #12081, implementation of Fixing breaking properties for emoji .
   The ticket is targeted for ICU 57. It’s taking more time than I originally expected. ICU4C should make the 2/28 check in deadline, but the ICU4J port most likely will not.
   
   Possible choices:

1. take it into ICU4J after the deadline - PMC agreed to do this - thanks Andy!
2. bump it out of ICU 57.
3. take it into ICU4C only.

3. ICU to Unicode

1. ICU license agreement letter draft was sent to Unicode Consortium, along with draft CLA form - waiting for consortium’s legal team’s review
2. √ Sent to Mark, Markus, Peter as FYI. (Steven)

4. 57 BRS assignment
5. ICU 57 API proposal status
6. Incoming  Please leave a lot of time for this, many old ones to go through
   

2016/02/17

1. ICU->Unicode

1. IP agreement on Unicode should be refined?

1. http://www.unicode.org/policies/ipr_policy.html 

2. Licensing changes related to Unicode migration after ICU 57? -> tentatively agreed.
3. Basically, need CLA that all 3 companies can agree to, as well as a copyright policy.

1. Markus driving on Google side
2. Peter for Apple
3. Steven for IBM

4. Expected documents for review to be available tonight. Includes a draft CLA akin to the current CLA. (So that would constitute something IBM could agree to)  (Steven)

2. Choices for @Discouraged [Scott]

1. JEP 277 http://openjdk.java.net/jeps/277  - proposes CONDEMNED, DANGEROUS, etc.
2. Action: add comments to Scott’s document, will review next week.

3. Incoming (many tickets are waiting for initial scan…)

1. Make sure to read ticket comments, not just the initial descriptions.

2016/02/10

1. ICU 57m1

1. tagged
2. Reviews
3. BRS

2. RC/GA 57 dates

1. See above

3. ICU move to Unicode status (license etc.)

1. next update expected next week  - still in review. steven
2. need to figure out how unicode will handle incoming changes

1. New CLA/JCA?
2. Apple had a ‘custom’ agreement
3. From feb 3: (Steven)

1. (FYI: new IBM OSS projects use a process such as this: CONTRIBUTING.md [similar to ICU’s, maybe updated wording])
2. (Node.js: Did away with CLA, went with a “shrinkwrap” agreement: CONTRIBUTING.md)

4. Action item - take this offline, do homework

4. Updates from UTC meeting? [Peter]

1. Text break updates for emoji (Unicode 9.0): New properties for Grapheme, Word, Line break; new rules for each

1. New rules implementation in progress (andy) – using UnicodeSet ranges in break rules, not yet new Unicode property values
2. Treatment of ZWJ is ugly in ICU break rules. Sometimes combining, sometimes not.

2. Others?

5. Choices for @Discouraged [Scott]

1. JEP 277 http://openjdk.java.net/jeps/277  - proposes CONDEMNED, DANGEROUS, etc.
2. Action: add comments to Scott’s document, will review next week.

6. JUnit for ICU - current status and questions (Stuart)

1. JUnitParams - Apache 2.0 license, makes parameterized unit tests cleaner and easier
2. We could depend on JUnit & JUnitParams by

1. Including .jar files in the repository
2. Use Maven
3. Prerequisite: Tell users they have to separately download & install ant, JUnit, JUnitParams, ...

7. ICU 57 API proposal status
8. Erase trailing whitespace (kazède)

1. Eclipse project settings -- turn on “erase on save”? – agreed

1. Yoshito: Also turn on “organize imports on save” – agreed

2. Not everyone uses Eclipse, but can set defaults in text editors (e.g. BBEdit) to strip trailing whitespace
3. Same requirement for icu4c? – agreed
4. Repo-wide clean-up? Could go together with Unicode copyright changes.

1. Needs to wait until the move to Unicode is actually being done.
2. +enforcement on checkin, like copyright date check now?

9. C++ UTF-16 string literals, have compilers progressed enough for us to use them? (Andy & Markus)
   Microsoft finally has them (and has always had 16-bit WCHAR string literals): https://msdn.microsoft.com/en-us/library/69ze775t(v=vs.140).aspx
   Feature comparison chart: http://en.cppreference.com/w/cpp/compiler_support

1. IBM to collect a list of compilers / support level requirements

10. Incoming

2016/02/03

1. ICU move to Unicode status (license etc.)

1. The Unicode board of directors approved the move of ICU to a Unicode Technical Committee.
2. What happens with the Joint Copyright Assignments? [Peter]

1. Existing IBM JCA: stays put
2. New terms of contributions with Unicode?

1. New JCA?

1. (FYI: new IBM OSS projects use a process such as this: CONTRIBUTING.md [similar to ICU’s, maybe updated wording])
2. (Node.js: Did away with CLA, went with a “shrinkwrap” agreement: CONTRIBUTING.md )

3. Future Copyright Statement  “text at top of file” (sent around by email)

1. Google: OK? [ looks fine ]
2. Apple: OK? [yes ]

2. ICU 57m1 status

1. CLDR 29 integration status - see below (copied from CLDR agenda this morning)

1. #9237 Fix uncommented text in Latin-Conjoining Jamo : Mark committed the fix last night
2. #9163 Remove non-functional ASCII-Latin transform : caused ICU test failure - needs ICU test case updated???

1. revert the change made by #9163
2. no ICU test case change

3. ICU transliterator does not have implementation for parsing -t- transform ID / Steven committed a quick patch to ICU : ICU bug #12077 -  (not assigned).
4. Territory containment - SS -> 014 : ICU test case needs to be updated.
5. We think translit problems have been fixed - John will proceed with integration activities.

2. Reviews - 0 as or now
3. Tickets with code changes, not in review status
4. BRS

1. to do for m1: urename.h update, CLDR 29 preintegration, ...

3. Handling new locale key “rg”, #12085 [Peter]

1. Already implemented in branch; roll in post-m1? – yes
2. Mark: would like to see rgScope added (cldr-dev email) - add for documentation use (maybe tests), not implementation
3. use all lowercase in documentation

4. Incoming

1. spam - anyone want to help add regexes? http://bugs.icu-project.org/trac/wiki/BadContent (Steven)

2016/01/27 - canceled

1. At UTC: Steven, Mark, Peter

2016/01/20

1. Jan 30 - 57M1 tag

1. light weight BRS - checking health?
2. John said he would start CLDR-to-ICU integration soon
3. Regular check in - Jan 27 (Wed)
4. Thu/Fri.. til Feb 3 (Wed)

1. Finish all pending reviews
2. subset of BRS - yoshito will create BRS worksheet

2. ICU/Unicode (Steven)

1. Jan 29 Unicode BoD meeting

3. ICU git mirror

1. https://github.com/icu-project 
2. authors: https://github.com/icu-project/icu-git/blob/master/scripts/authors.txt 
3. Use git for main repo? A lot of work to switch workflow, bug tracking, and especially cross-links between tickets and changesets. Not for now.

4. Preliminary discussion on mapping usage to units (in API proposal status doc) - Peter
5. ICU 57 API proposal status
6. Incoming

2016/01/13

1. ICU/Unicode (Steven)

1. IBM Process: complete. √☑✓✔
2. Awaiting Unicode BoD approval / agreement sign off

1. license/agreement text by Mon, Jan 25th
2. sign off Fri Jan 29th at BoD meeting - http://unicode.org/timesens/calendar.html 

3. Announcement: Target Mon, Feb 8th?
4. Questions:

1. Future license text?
2. Future source file copyright lines?
3. Continue to update copyright date range for first year to last update, or only first year, or only last-update year?
4. Which of these should it be:

1. © 2011-2015 Unicode, Inc., IBM
2. © 2011-2015 Unicode, Inc.
3. (© – Cannot use non-ASCII characters in .h/.c/.cpp files.)

2. RelativeDateFormatter API issues and plain C APIs [Peter]

1. Sent preliminary discussion to icu-core on Jan 11, Markus replied Jan 13
2. After feedback will send formal proposal to icu-design
3. For #12072, RelativeDateTimeFormatter plain C wrapper API
4. Agreed to propose new APIs for J, C++, C that use unified approach: new unified enum for date fields, new enum for style (text vs numeric), and use signed offset to get direction (no direction enum)

3. Datetime formatting (kazède): if pattern character count isn’t defined in the spec, what’s the appropriate behavior?

1. Currently it’s either no-op or defaults to an arbitrary case.
2. Along the same line: what to do with unsupported pattern character in the pattern? (current behavior: treated as a numeric field and padded with zeros.)
3. Clarify in CLDR spec (this part)? ICU user guide (this part)?
4. Discussion last September, inconclusive so far:
   [proposed:2015-09-02] ICU C/J behavior: pattern character fields with too-long lengths in SimpleDateFormat, DecimalFormat

4. ICU resource data loading overhaul (Markus)

1. consensus - Markus + googlers to continue to work on this transition

5. Line Break of R$  (#11556) (andy)

1. OK to add rule change separately from Unicode update?

6. ICU 57 API proposal status
7. Incoming

2016/01/06

1. ICU/Unicode (Steven)

1. Waiting for one more approval in IBM - almost there on IBM side

2. Can we remove UDAT_TIME_SEPARATOR_FIELD in udat.h?

1. See details in 2015/12/16 minutes
2. Markus wants to make it @internal but will wait for Peter.
3. Change of numeric value may be a problem for identifying fields in format/parse (Peter)? - actually it is not
4. Related C++ code is #if-ed away via UDAT_HAS_PATTERN_CHAR_FOR_TIME_SEPARATOR
5. Peter agreed to make it @internal - so PMC approved.

3. DateIntervalFormat.format() thread safety, #11669. (Andy)

1. For C++ the format() functions are declared const, and I have brute-force fixed the thread-unsafe behavior with mutexing.
2. The corresponding format() functions in Java are also not safe. Should they be fixed, or should we just document the unsafe behavior? Possible precedent from DateFormat:   “Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.” - separate ticket - what to do with ICU4J DateFormat? Make format() thread safe? no changes?
3. Should we develop a standardized piece of boilerplate to be included with the API docs of any Java function that is logically const and safe for concurrent use?
4. ICU4J marking thread safe methods - http://bugs.icu-project.org/trac/ticket/12057

4. Incoming
5. Mark: #11905

1. [{b}] = [b] // works right now
2. [a-{xy}] // will always fail; second part of range must resolve to single code point
3. [a-{x}] // would succeed if we do 11905
4. [a-\u0062] works
5. [a-\x{62}] works
6. [{é}-{ë}] // may be unexpected per http://bugs.icu-project.org/trac/ticket/11738 ?
7. [{ä}-{z}] // fail

2015/12/30 canceled

2015/12/23 canceled

2015/12/16

1. Can we remove UDAT_TIME_SEPARATOR_FIELD in udat.h? (kazède)

1. Also in Java: DateFormat.TIME_SEPARATOR
2. It’s still in draft status.
3. More fields are coming in after it (b & B).
4. The enum wants to stay in sync with the string of pattern chars. It does not really work to have a gap in there.
5. http://bugs.icu-project.org/trac/ticket/11773 “Delete colon as pattern char”
6. Agreed to keep the TIME_SEPARATOR field constants but ok to change their numeric values, so that the supported ones including b/B are contiguous
7. Markus wants to make it @internal but will wait for Peter.

2. Measurement unit data loading progress (Markus)

1. Now handles per-string, per-plural-form parent fallback, sideways aliases, and plural fallback (e.g., “one” -> “other”); both Java & C++
2. With infrastructure in place, the data loading & data using code is not much longer.
3. Craig has started working on doing the same for relative date/time formatting
4. Plan to slog through ICU, change to resource enumeration, handle all fallbacks

1. umbrella ticket: http://bugs.icu-project.org/trac/ticket/11584 "Cleaner and less fragile RB access"
2. zone names

1. done in J: http://bugs.icu-project.org/trac/ticket/11879 “optimize TimeZoneNamesImpl.java”
2. C++ TBD: http://bugs.icu-project.org/trac/ticket/11912 “optimize C++ TimeZoneNamesImpl, add & use table resource enumeration”

3. measurement patterns - done for ICU 57

1. http://bugs.icu-project.org/trac/ticket/11986 “incomplete fallback in MeasureFormat”
2. http://bugs.icu-project.org/trac/ticket/12030 “MeasureFormat handle by-plural-form sideways-aliasing”

4. relative date/time: http://bugs.icu-project.org/trac/ticket/12018 “en_GB relative time strings missing "other" for some cases”
5. interval format: http://bugs.icu-project.org/trac/ticket/12013 “resource enumeration for DateIntervalFormat”
6. Markus to create a doc with a list

5. Help would be welcome

3. ICU 57 schedule

1. Dates updated above ↑↑↑

4. (ICU-under-Unicode - legal review still in progress [/-\-/-\-…]
5. Incoming

2015/12/09

1. Meeting schedule over the next few weeks
2. FYI: Swift would like ICU regex support (per Apple 23382675) for:

1. UREGEX_CANON_EQ
2. “language-sensitive regular expression matching” (need more details)
3. IBM team requested ‘collation sensitive’ regex support (somewhat like POSIX)
4. Need very specific definition of exactly what is requested

3. ICU move to Unicode: still under legal review
4. Windows XP revisited: Mozilla Firefox would like it to continue. (Andy)

1. Markus asked back “for how long?”, no answer yet
2. http://windows.microsoft.com/en-us/windows/end-support-help “Windows XP support has ended”

1. “As of April 8, 2014, support and updates for Windows XP are no longer available.”

3. Andy to ping Jonathan <jonathan@jfkew.plus.com> in support list - and find out what they want / timeframe for dropping XP support in Mozilla, etc.

5. Other topics...
6. Incoming

2015/12/02

1. Drop ICU support for Windows XP? (Andy)

1. Peter: Apple is OK with this (our Windows products currently require Windows 7+)
2. Yoshito: IBM is OK.
3. Agreed to drop Windows XP support in ICU 57

2. Drop ICU support for Mac OS X 10.6? (Markus)

1. Apple is OK as far as released version, but:
2. Problem for build bots, which run OS X 10.5 and 10.6 ?

1. Michael: moonlight is running 10.11, other Macs would be removed

3. Peter has asked Celia to have Apple consider contributing a new Mac Pro to Unicode which could be used for ICU build bots, as well as Unihan, CLDR Smoketest, etc.
4. Yoshito: IBM is OK.
5. Agreed to drop 10.6 support in ICU 57

1. Steven/Michael to update continuous build systems and drop old Mac OS systems

3. ICU resource bundle data loading with fallback (Markus)

1. Several tickets with problems & optimizations

1. For example, http://bugs.icu-project.org/trac/ticket/11986 “incomplete fallback in MeasureFormat” has two issues, fixing second one now

2. Ported ICU 56 Java resource enumeration to C++; was developed for faster time zone names loading, now used to fix measurement unit formatter data loading
3. Found problems in relative date/time formatting: http://bugs.icu-project.org/trac/ticket/12018 “en_GB relative time strings missing "other" for some cases”
4. For unit data fixes inheritance from parent, but hard to handle sideways inheritance; need to address that in the data (fleshing it out)
5. Planning to pull this into more ICU services
6. Speak up if you disagree...
7. Easy to handle: “one” in en_GB, “other” in en
8. Easy to handle: “one”/”other”/plural forms in units, “dn” and/or “per” needs sideways-alias to unitsShort
9. Hard to handle: “one” in units, “other” needs sideways-alias to unitsShort

1. Markus asked Mark to propose to CLDR that this per-plural-form sideways-aliasing is not needed in code – data would be fleshed out so that plural forms travel as a group within a width

10. Need to make CLDRModify minimization match what ICU actually does (once ICU behavior for C and J becomes consistent). Can we test this somehow?

1. Note that JSON generation already fully fleshes out the inheritance, can use this for testing

4. ICU 57 API proposal status
5. ICU4J minimum JRE version to 6

1. Markus asked Fredrik to work with Yoshito & srl on instructions & maybe build bot for testing against Android API

6. Incoming

2015/11/25 canceled

(Peter, Markus, Yoshito away for 11/25 meeting)

2015/11/18

1. Drop ICU support for Windows XP? (Andy)

1. Chrome drops support for XP and Vista in April, 2016, which eliminates Google’s need. Dropping XP would allow significant cleanup and simplification of the ICU synchronization primitives. Does anyone else require XP support?
2. we would have to ask around our community. Might be more feasible (from a requirements gathering pov) for post 57. (steven)
3. Action items

1. Andy to send a note to icu-design, ask about both XP & 10.6
2. Apple / IBM will check with each internal group - back in 2 weeks (by PMC on Dec 2)

1. Peter: Apple is OK dropping XP (our Windows products currently require Windows 7+)

2. Drop ICU support for Mac OS X 10.6? (Markus)

1. Chrome also drops support for 10.6-10.8. I believe that 10.6 was the last one with an old glibc without C++11. Is it a gating item for certain ICU code paths?
2. one could also rebuild gcc for 10.6 (Steven)
3. One of our machines -macx [Macmini1,1] is still 10.6 (steven) - System Version: Mac OS X 10.6.8 (10K549) - Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)
4. For example, drop 10.6 from the ICU 57 version of the supported-platforms list like on http://site.icu-project.org/download/54

3. Meeting next week? (day before US Thanksgiving. Peter away). Decided to cancel.
4. ICU 57 API proposal status
5. Incoming

2015/11/11

1. ICU under Unicode (Steven)

1. Accepted by Unicode EMG
2. Needs IBM review
3. Structure: new “ICU-TC”

1. needs chair, vice chair
2. provisional (just to have something on record) Mark chair, Steven vice chair.
3. consensus to propose Yoshito as chair, Markus as vice-chair to Unicode officers
4. decisions taken by consensus, same operation (like CLDR-TC)

4. PMC should formally vote to accept this (can be by email)

1. YES        Mark Davis        Google
2. YES via email        John Emmons        IBM Corporation
3. YES        Doug Felt        Google
4. YES via email        Deborah Goldsmith        Apple
5. YES        Steven Loomis        IBM Corporation
6. YES        Markus Scherer        Google
7. YES        Peter Edberg        Apple
8. YES        Yoshito Umaoka        IBM Corporation
9. Agree that it passed, but want it to be unanimous. So Peter to contact Deborah and Steven/Yoshito to contact John. (done)

5. Schedule:

1. Unicode officers need to accept chairs (not a blocker)
2. Unicode establish TC materials
3. Announcement by Dec 15 (?) or so, depending on IBM review.
4. Markus and few others to work on the Unicode announcement text. Steven the POC for the IBM announcement
5. Change ICU license ownership; Mark as POC for Unicode legal.
6. Fix ICU web site & User Guide; API docs??

1. branding/copyright

7. Fix Unicode web site, mention new TC etc.
8. Website fixes don’t have to be timed with the announcement: just news item on each home page.
9. May want build option to change the ICU4J package prefix from “com.ibm” to “org.unicode” or something parameterized. (Nice to have, no blocker.)
10. Licence will change for v57, but not previous versions. Will need both licence statements.

6. Build bots / build lab? [Peter]

1. No planned infrastructure changes
2. May make it easier to find hardware for this
3. IBM not de-committing resources

2. Minimum Java runtime

1. previous discussion: Java 7 - minus stuff not available in a certain version of Android SDK
2. should we really go for Java 6?
3. considerations

1. Versions

1. Java language syntax level - X
2. Class file version - Y
3. Runtime version - Z
4. it must be X <= Y <= Z

2. Runtime library vs Test/Tools

1. Can use different versions - for now

1. core/charset/collate/translit - tests - 5
2. locale-spi / locale-spi test - 6

4. consensus - java 6 ∩ Jelly Bean

1. language syntax/class file version/minimum runtime for ICU 57
2. https://developer.android.com/about/dashboards/index.html
3. https://en.wikipedia.org/wiki/Android_version_history
4. Markus proposes that we try to support Android 4.1[.2] Jelly Bean API level 16 (July 2012). That supports some 92% of current devices according to the Android dashboard.

3. Incoming

2015/11/4 -  [UTC] / no meeting

2015/10/28 - Unicode conference / no meeting

2015/10/21

1. ICU 57 schedule

1. CLDR agreed to have data freeze date (final data/tools candidate) of Feb 15, see schedule
2. CLDR can still fix data bugs after that if requested by ICU
3. CLDR 29 overall final candidate is March 1, release March 15
4. ICU release could be Weds Mar 23 or 30 -> agreement : March 23

2. Incoming

2015/10/14

3. ICU 56

1. ICU 56 BRS open items
2. Still-open tickets

1. roll over to new milestone type? or UNSCH? --> 57m1
2. Some team members might close “nice to have” tickets with a new resolution like “unscheduled”, and link to them from a page on, say, the design section of our site, or a new “nicetohave” section.

4. ICU layout engine tickets (Markus; see email with this subjec

1. tickets with keywords=ParagraphLayout – Steven reviewing whether the keyword is appropriately set
2. open layout-but-not-ParagraphLayout tickets – TODO(srl): close with “wontfix”, with comment
3. Does it make sense to remove the low-level layout engine code and hard-wire the ParagraphLayout to work only on top of icu-le-hb?

1. http://userguide.icu-project.org/layoutengine/paragraph
2. Start with by default turning off building layout engine, Steven to file ticket

5. ICU 57 schedule

1. end of Q1, 2 weeks after CLDR 29
2. request CLDR to set ‘data freeze’ date, hopefully early March

6. Upgrading minimum Java execution environment

1. Java 6
2. Java 7, minus APIs not supported by Android SDK - go for this one
3. Java 8, minus APIs not supported by Android SDK

7. Incoming

2015/10/07

1. ICU 56 release

1. ICU 56 BRS

2. Live updates to timezone data, #11946

1. concern (Steven):

1. UDate a,b;
   UnicodeString str(“1/1/11”);
   {
     DateFormat f; ...
     a = f.parse(str)
   }
   // -- data reloads here
   {
     DateFormat f2;
     b = f2.parse(str)
   }
   Problem:  ( a - b) != 0

1. Andy: “but this might be less bad..”
2. Workarounds:

1. If the user manually creates the TZ object, can ensure consistency.
2. reuse of Formats / Calendar / etc.

2. Notification?

2. Yoshito:  use tz version in the path

1. use tz version as resource key

3. How often to check?

1. not every time creating a DateFormat object – performance
2. at most every <interval>, e.g., 5 min?

4. Goal to implement without app developers having to change how they do things
5. flexible options (Steven)

1. callback:  UBool callbackHasChanged()  returning true/false whether to immediately change new instances
2. TimeZone::updateData() - “It’s OK to reset timezones”
3. Global (env/compile/runtime flag):  TimeZone::allowImmediateUpdate(UBool)

6. Scope:   what about other default locale changes? (Steven)

1. change in default locale id or some component
2. change in custom formatting
3. change in default time zone

3. Incoming

2015/09/30

1. ICU 56

1. Recent email about security issues: should we fix these in ICU 56? (Markus)

1. #11865

2. ICU 56 BRS
3. Trunks mostly open, except hold off on big structural changes for now.

2. ICU structure and ownership (Steven)

1. IBM sole corporate steward
2. Good technical processes (releases, design & API discussions)
3. Might attract more collaborators with more open structure?
4. Separate foundation?

1. involves a non trivial amount of work - and cost.

5. Move under Unicode Consortium “Implementation-TC”? Maybe as a sibling of Unicode-standard release tools?

1. Already tightly interlocked with Unicode Standard & Unicode CLDR.
2. Pros and cons of TC structure.
3. Might be new structure.

6. Q: Copyright/License?

1. License might be granted to new owner, transfer/single grant probably better than perpetual assignment. Maybe “Portions copyright IBM & others” - in a single file somewhere.
2. Going forward: New copyright structure, determined by new owner.
3. License in / out no more burdensome than now.
4. Make sure that all the pieces of the code & site go with.
5. Make sure that the wording of the licence remains as is!
6. Unicode Terms & Conditions page: Code x is governed by license y which is substantially the same as the Unicode license.

7. org.unicode.icu? (icu4j package name)

1. … and https://icu.unicode.org  (site)

8. Not decrease in involvement by IBM, but rather a more formal process.
9. Consider build lab owned by new org. Contributors might sponsor machines & share access.
10. Structure going forward (Steven):

1. no change to weekly  or release technical structure/processes - “icu-core” (oddly similar to CLDR process)
2. the “Implementation-TC” would be a parent, governing body (might just approve new subprojects)
3. Mark: Works only if we don’t change any processes. Move to Unicode, no real changes, then change only what is necessary. Don’t try to invent new processes/structure ahead of time.

11. Timeline: Not a short term change.

1. srl would propose in some more detail to Unicode officers on Nov 6 2015, Unicode BoD end of Jan 2016.

12. PMC is generally in favor of this, but wants to get the details ironed out.

3. Travis will no longer be attending weekly ICU meetings after today. Travis’ email: travis.icu@gmail.com

1. Reassign tickets to someone else
2. Work in progress: DecimalFormat in branch, Andy aware of status

4. Incoming

2015/09/23

1. ICU 56 RC status

1. ICU 56 BRS
2. Under review: Review • reviewfeedback
3. Active tickets with trunk changes: http://bugs.icu-project.org/trac/report/24
4. ICU4C

1. 2022 change test failure on solaris - http://bugs.icu-project.org/trac/changeset/38002 

5. ICU4J

1. A few test failures

1. IBM Java 8 - fixed r38008
2. format module test

6. Peter to fix createGeneric, createRevolution; will need to regenerate API change report; file a ticket for ICU 56 to do this, and one for ICU 57 to add exceptions to generator process; #11929

1. cldr

1. temperature-generic
2. angle-revolution (but in common usage this is not tied to angle, e.g. revolutions per minute, or turn 3 revolutions)

2. C MeasureUnit methods

1. createGeneric -> createGenericTemperature
2. createRevolution -> createRevolutionAngle

3. J MeasureUnit constants

1. GENERIC -> GENERIC_TEMPERATURE
2. REVOLUTION -> REVOLUTION_ANGLE

2. Download page
3. Incoming

2015/09/16

1. API promotion draft

1. ICU4C (Michael)
2. ICU4J (Scott)

2. BRS

1. ICU 56 BRS

3. Open tickets

1. Under review: Review • reviewfeedback
2. Active tickets with trunk changes: http://bugs.icu-project.org/trac/report/24
3. Other open tickets
4. MD: I think http://bugs.icu-project.org/trac/ticket/11898 is important to fix (and a small change). I have to leave now, however. PE: So do you want this ticket?? (Mark said yes) - assigned to Mark as critical/56.1
5. 11435 (SmartOS): set to review 56  (everything reverted),  fix in 57 in 11881 (assign to srl).  Close 11882 as dup.
6. 11689 (VS2015): set to review 56 (comp issues fixed, tests todo). fix in 57 in 11822 (assign to srl, reopened)

4. Release task tickets

1. C: #11917
2. J: #11918

5. IncomingBugs / Review • Review feedback

2015/09/09

1. API Proposals for ICU 56
2. CLDR 28 status

1. No more data changes anticipated
2. Still doing spec updates, spec in beta (in review period for spec until Monday)
3. Expect to have draft download page by Monday or so
4. Release next Wednesday

3. Feature freeze for 56 is planned today (soft freeze*, still finishing some urgent items that may take a few more days)  (*emphasizing APIs?)

1. Remaining items?

1. Markus will try to get one more staticanalysis ticket done

4. IncomingBugs / Review • Review feedback

2015/09/02

1. Feature freeze next Wednesday: 2015-09-09 (Wed): Final check-in for features/regular bug fixes (Feature Freeze)

1. Any items need more time?

1. Peter has a few new API items, will try to send proposals to design list today, roll in before API approval then adjust as necessary per API approval
2. Steven has one - filter break iterator / promotion

2. API status promotion draft

1. Target - @draft ICU 54 or before
2. ICU4C - Michael
3. ICU4J - Scott
4. by Sep 14

3. Java 6/7 as base for ICU4J (Markus)

1. Most of Java 7 (as far as is useful for ICU) should be ok for Android, Google will test frequently, will work with Yoshito to see what we can do for optional Eclipse setup to flag use of APIs not available on Android (need to see which Android SDK level should be the base)
2. Want to set Java 7 (& some Android SDK level) as base for ICU4J 57
3. Scott to check on Java 7 with Eclipse team

4. API Proposals for ICU 56
5. IncomingBugs / Review • Review feedback

2015/08/26

1. Java 6 please for ICU4J (Markus)

1. See team email with this subject aug20: java.text.CollationKey changed from final to abstract
2. It looks Eclipse platform team is OK to move up to 6, 7, or even 8 for next release
3. Google might have a problem with Java 7 as minimum… - Markus will check (see sep02 meeting)
4. Apple is fine with Java 6 and 7 as minimum (but not Java 8)
5. “risky” to try to do this for ICU 56

2. ICU4J 56 - JDK8 JavaDoc support

1. If it’s difficult to maintain two target env - JDK8 and JDK7 or before, we may just support JDK 8+ (and skip building API doc on JDK7 or older)

3. Ok to remove unused impl .java files? (Markus)

1. E.g., com/ibm/icu/text/BreakCTDictionary.java
2. (maybe IntTrie after changing the CharsetSelector)
3. easy way to find unused impl classes? testing? code coverage?
4. careful with “public impl class” which might be used by CLDR

4. API Proposals for ICU 56
5. ICU4J UFormat class is wholly @draft, awkward for publishing *Format subclass API docs (Markus)

1. Marked as @draft/@provisional (retains this status since 2.8)
2. Markus: Make class UFormat and its default constructor @stable but keep its getLocale() method @draft? - agreed
3. Markus to file a ticket to track this one. will be included in 56 API status promotion list. → http://bugs.icu-project.org/trac/ticket/11875

6. How to safely detect signbit on all platforms? Markus mentioned that <math.h> signbit() may not work on windows, but it fails on solaris too. (Travis) uprv_isNegative()

1. What’s wrong with uprv_isNegative? [George]

7. CLDR decided to deprecate colon as a date pattern character [Peter], relates to #11773

1. Will keep the time separator symbol/structure/mechanism for possible future use
2. May use a different character in the future as pattern char for time separator (something that would not normally occur in a date/time pattern); the problem was with using colon
3. Keep the time separator field as a date format field but just have no pattern char for it - agreed
4. Peter to send something to icu-design, update #11773 to adopt this solution, have something in readme

8. incomingBugs / Review • reviewfeedback

2015/08/19

1. API Proposals for ICU 56
2. Coverity / source code scan problem fixes

1. Michael to take the ownership
2. Trac ticket keyword “staticanalysis”

3. ICU readonly git mirror (Steven)

1. lots of mirrors on github
2. readonly - would not accept bug/issue reports nor ‘pull requests’

1. although, PRs could be a good way for users to document  patches.

3. source would be on icu-project.org but not hosted (via http) on our server
4. would make it easier for downstream users using git to manage their own patches against ICU
5. proposal: one org (github.com/icu-project) several repos (data icu[4c] icu4j icu4jni icuapps icuhtml tools)
6. non-goal: “move to git”
7. Agreed : Steven to work on this.

1. store authors map in svn repo

1. srl ->  <someemailaddress@...>
2. default: srl@<UUID>

2. repo:  github.com/icu-project

4. (Travis) Addendum to DTPNG::staticGetSkeleton and staticGetBaseSkeleton proposal: Advertise that callers can pass NULL for the DTPNG handle to the corresponding C API versions of these methods – rather than add new C APIs corresponding to the new static C++ methods. (#11779)

1. int32_t udatpg_getSkeleton ( UDateTimePatternGenerator *  dtpg, const UChar *  pattern, int32_t  length, UChar *  skeleton, int32_t  capacity, UErrorCode *  pErrorCode  )
2. also udatpg_getBaseSkeleton(dtpg, ...)
3. update API docs that the first param can be NULL (or simply state first param is not used for now)
4. PMC agreed.

5. ICU4J in Android (Markus)

1. In the system, in AOSP (Android Open Source Project) (browse ICU source)
2. jarjar’ed from com.ibm.icu.* to android.icu.* in order to avoid conflicts with apps that carry their own copy of ICU4J
3. Investigating exposing parts of the ICU4J API as part of the Android SDK

1. Will probably hide draft/deprecated/...?

4. This would include publishing relevant parts of the ICU4J API docs as part of the Android SDK documentation
5. Peter: webkit has a directory with some ICU headers, not sure they count as API; some webkit apps use some of them
6. Steven: Put this on the project page or FAQ, e.g., how to build ICU on Android, in future (if this works out) using Android’s version instead
7. Yoshito: need to do something for ICU4J development with IntelliJ?

6. Incoming bugs

1. #11773, Peter to put discussion on CLDR agenda

1. Added for 2015-08-26, see CLDR ticket #8905

2015/08/12

1. ICU 56 RC/GA dates (approved)

1. 2015-09-09 (Wed): Final check-in for features/regular bug fixes (Feature Freeze)
2. 2015-09-14 (Mon): API change report updated for review (new APIs, status changes)
3. 2015-09-16 (Wed): Final check-in (response to code review, except some BRS items)
4. 2015-09-23 (Wed): ICU 56 RC
5. 2015-10-07 (Wed): ICU 56 GA

2. Indic search behavior (Peter)

1. http://bugs.icu-project.org/trac/ticket/11750 “Search should allow match end in middle of combining seq before char with primary weight”
2. http://www.unicode.org/reports/tr10/#Searching
3. Test for normalization boundary: If character before has normalization boundary-after, or character after has normalization boundary-before, then it’s ok. (Use Normalizer2.)
4. Summary: When break iterator is not provided by user - search match can return index in the middle of character grapheme as long as it’s normalization boundary.

3. Adding new RBNF syntax for Infinity, NaN and alternate decimal points (George)

1. http://bugs.icu-project.org/trac/ticket/11760
2. George proposed new syntax on aug08 “[icu-design] Add syntax to RuleBasedNumberFormat for Infinity, NaN and alternate decimal points”
3. ICU PMC approved the proposal - George should alert CLDR again / this change will be merged into CLDR soon.

4. Metazone & test updates for tzdata2015f (Uruguay no more DST, Moldova DST transition at 0:00 not 1:00, North Korea to +0830) [Peter]

1. CLDR decision - just remove North Korea from current “Korea” metazone, but don’t yet add a new metazone for North Korea (so will get fallback formatting)

5. API Proposals for ICU 56

1. Travis to submit followup ticket for staticGet[Base]Skeleton() in Java.
2. http://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table 

6. DecimalFormat update (Travis) - Updated version implementing Mark’s VisibleDigits class. Much better performance than previously. We want this version to go to the trunk.  https://codereview.appspot.com/256440043
7. Characters for day periods:

1. We currently use [aA c dD eE F gG hH jJ kK lL mM O qQ r sS uU vV wW xX yY zZ]
2. Java also uses [nN p] (nanoseconds & padding)
3. Unused: [bB C f iI o P R tT]
4. Possible (see CLDR #8862)

1. b - am/pm/noon/midnight
2. B - dayperiods (fallback to am/pm)
3. C - preferred form of [a,b,B] for locale, like j for h/k/H/K

Rule syntax for formatting and parsing alternate decimal points are being updated so that 0.x, x.0 and x.x remain unaffected and the default, but when the decimal point matches the DecimalFormatSymbols value for the decimal point, that will be used instead of the default one with the full stop.

Inf: infinite;

NaN: not a number;

x.x: << point >>;

x,x: << comma >>;

[steven] with the same rbnf rule but in locales w/ different decimal format symbol for decimal point

((float)123456/1000f) in “en_US”  -> One hundred twenty-three point four five six

((float)123456/1000f) in “en_150” -> One hundred twenty-three comma four five six

2015/08/05

(Peter out, on vacation)

1. UnicodeSet syntax for range of strings (Mark)

1. http://bugs.icu-project.org/trac/ticket/11738

2. http://unicode.org/cldr/trac/ticket/8616#comment:2
3. Markus: “{ab}-d” seems too confusing, better require len(X)=len(Y)
4. http://www.unicode.org/repos/cldr/trunk/common/validity/language.xml 
5. {ab}-{ad}
6. {abc}-{cd}  <-  bad syntax.   throw exception?

1. Markus: I am not sure UnicodeSet throws exceptions for bad syntax; this should handle any bad syntax like other bad syntax.

7. http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3Aemoji%3A%5D 
8. {x`}-{x’} (but with NSM) ?
9. Agreed, if the lengths are defined to be the same (otherwise syntax error).

2. DecimalFormat rewrite (Travis) - Go / no go?

1. team email “Memory map of new DecimalFormat class”
2. team email “Heap usage exercise with DateFormat”
3. Peter (last week) and Steven (today) both replied affirmative
4. ICU PMC agree to merge this to ICU4C trunk

3. Numbering systems outside BMP? (Steven)

1. http://unicode.org/cldr/trac/ticket/8837  - CLDR
2. http://bugs.icu-project.org/trac/ticket/9488 - Yoshito has a ticket on this? updated

1. related to http://bugs.icu-project.org/trac/ticket/10368 

3. http://bugs.icu-project.org/trac/ticket/9489 - “DecimalFormatSymbols currently cannot handle decimal digits out of Unicode BMP. ICU4J implementation currently detect this and use Latin digits as the fallback. ICU4C implementation should also do the same.” - Yoshito’s
4. Consensus:

1. CLDR should remove draft=provisional from relevant data
2. ICU4J falls back to ASCII digits until fixed
3. We should document that, repurpose ticket #9489 for this (rather than changing C) done
4. Fix of ICU4J would support supplementary digits, would add “List<String> getDecimalDigits()” or similar, and char-returning getDigits() and getZeroDigit() would fall back to ASCII -> #9488
5. Travis to check ICU4C - (Travis) ICU4C does support non BMP digits as DecimalFormatSymbols represents the symbols (including digits) as an array of UnicodeString.

4. Filtered (ULI) break (Steven)

1. improvements merged on C http://bugs.icu-project.org/trac/changeset/37721  - forward/back, passes tests

1. <locale en@x-uli=true&ss=standard>

2. C todo: perf, thread safety
3. J todo

5. coverity (Steven)

1. need help to triage issues within coverity
2. alejandro.joya.cruz at intel.com wanted to join our ‘coverity’ project

6. https://www.youtube.com/watch?v=8cwWgxbqah0 

2015/07/29

(UTC #144) – participation of Mark & Peter in ICU meeting depends on UTC schedule

• Meeting cancelled, but will discuss go/no go on merging DecimalFormat #11740 by email.

2015/07/22

1. DecimalFormat rewrite (Travis) - We have a rewrite of the DecimalFormat class in a branch. The new code is C++ only.

1. http://bugs.icu-project.org/trac/ticket/11740

1. branch: http://bugs.icu-project.org/trac/review/11740#icu/branches/tkeep/11740
2. review link: https://codereview.appspot.com/238210043/

2. This new code offers the following advantages over the old legacy code.

1. Const methods are actually const and thread safe
2. Code broken into small independent modules for easy testing and maintenance
3. Formatting small ints over 3X faster than old code
4. Many other formatting use cases faster as well

3. Caveat:

1. Memory footprint increase of just over 50% per object

1. what are the actual byte sizes, old and new? -Peter
2. 4kB (5 memory blocks) → 6kB (2 memory blocks)
3. no heap allocation during format() except internal to UnicodeString etc.

2. Would be good to know the memory footprint impact on SimpleDateFormat which has several NumberFormat objects (Peter)

1. first SimpleDateFormat alloc in a process
2. memory use after first format with that SimpleDateFormat
3. memory use after first parse operation with that SimpleDateFormat
4. Not just size of the SimpleDateFormat object itself, need to measure total heap use to account for caching
5. Peter: On MacOS X try “man 1 heap” tool, in the test code use sleep(10) etc.

1. e.g. program launches, then calls sleep(10) and prints message to check initial heap; then allocs a SimpleDateFormat and calls sleep(10) again and prints message; then uses the SimpleDateFormat to format, calls sleep(10) again, etc.
2. At each sleep(10) and message, run “heap <procname>” from another Terminal window, use info to track increase in heap.
3. Do before and after the changes for new code.

6. Results of this exercise explained here: https://docs.google.com/document/d/1cwcKmn6xRUVfteAs9s0N4i4YWsBMVHngxlcacSscDgk/edit?usp=sharing

4. Spreadsheet with all the metrics:

1. https://docs.google.com/spreadsheets/d/1ALIOzYyhXaCGgWj1VsRVfI6-VaFO0F7qS4pAAfwaZpA/edit?usp=sharing

5. Ok to merge into trunk after review?

1. Mark & Andy are reviewing now.
2. Steven wants to look too.

6. Ok to fix the memory footprint after trunk merge, possibly after ICU 56?

1. Ideas: caching and shared objects for things like DecimalFormatSymbols & maybe NumberingSystem
2. TODO: Check SimpleDateFormat memory usage before merging into the trunk (requested by Steven & Peter) – see details above under “Caveat”
3. TODO: Steven wants to look at the DecimalFormat memory usage before the ICU 56 release (can be after merging into the trunk)

7. Note: We will wait with a Java port until the C++ code has had some more work to make it easier to port.

2. IncomingBugs / Review • reviewfeedback
3. Meeting next week during UTC?

2015/07/15

1. Security patch policy

1. IBM wants to apply security patches back to latest GA version - 2
2. For the latest - official maintenance update
3. For backlevel streams / merge the fix if necessary + tag the version + source patch (trac diff link) posted in ICU version download page, but no binary release (by default)

2. IUC presentations due next Friday
3. Schedule for CLDR data integration, late August [Peter]

1. Data freeze is Aug 17, integration takes around a week or so after that

4. IncomingBugs

1. #11773, Peter to first check with CLDR about withdrawing colon as pattern char; else consider something like “colon mode”

2015/07/08

1. BCP47 keywords to control use of ULI segmentation suppression, and to select CSS word-break options for line break [Peter]

1. Proposal
2. CLDR locale keys/values
3. Implementation issues

1. uli (filtered break)

1. 11248 (forward/backward)
2. 11769 (Move FilteredBreak into draft, maybe move to common)

7. IncomingBugs
8. build failures

1. C data in J failing since http://bugs.icu-project.org/trac/changeset/37644  - collation failures – fixed in r37654
2. data port / trunk win - ‘assert()’ added in http://bugs.icu-project.org/trac/changeset/37649 – fixed in r37653

2015/07/01

1. ICU 56m1

1. http://site.icu-project.org/download/56m1
2. active tickets - http://bugs.icu-project.org/trac/report/24
3. Review 
4. ICU4C api change report - not updated yet

1. regenerate
2. re-tag milestone-56-0-1 - steven will work with michael

2. IncomingBugs

2015/06/24 (deadline for m1 checkins)

New meeting time: 10-11am (Pacific Time) / 1-2pm (Eastern Time)

1. ICU 56m1

1. Download page: https://sites.google.com/site/icusite/download/56m1
2. ICU 56 BRS: https://docs.google.com/spreadsheets/d/1y4vdAjBZ7tHtZ6FRwKJ4CuHldEK92eN_Y2plFr4dKbI/edit#gid=0

2. IncomingBugs / Review • reviewfeedback

2015/06/17

1. Move off of sourceforge

1. http://fossforce.com/2015/06/sourceforge-not-making-a-graceful-exit/

1. issue: sourceforge was wrapping downloads in “junkware”/malware with and without permission from owners

2. Could use google groups for email lists

1. Make sure we have copies of the mailing list archives

3. downloads as a CDN? (not a completely turnkey process, but it does save a lot of server load.)
4. Actions: Mark to create a few groups, Fredrik to try to import existing archive

2. Adjust CLDR vs ICU meeting times - add 15 min for CLDR, remove 15 min from ICU (start later)? [Peter E]

1. will discuss in next CLDR meeting

3. Latest CLDR svn data is in ICU
4. IncomingBugs / Review • reviewfeedback

2015/06/10

1. ICU4J locale spi problem on Java 8

1. http://bugs.icu-project.org/trac/ticket/11733
2. Impacts - running ICU4J as locale provider on Java 8 and use DateFormat (DateFormatSymbols) throws NPE
3. Root cause -  Java DateFormatSymbols constructor calls this.clone() and cache a copy.  ICU’s JDK class wrapper (com.ibm.icu.impl.jdkadapter.DateFormatSymbolsICU) has a field ‘fIcuDfs’ initialized by the constructor, but when clone() method is called, fIcuDfs is not yet assigned. [http://bugs.icu-project.org/trac/changeset/37501]
4. Filed a bug in the Java bug database, also discussed the issue in java-i18n ML - and Oracle folks agreed that JDK implementation is problematic.
5. The fix is only in locale-spi module, not ICU4J core jar. The fix prevent NPE when fIcuDfs is null. The fix is good enough for the current Java 8 implementation.
6. Actions:

1. merge the fix in maintenance branches
2. post locale-spi jar for 55.1 and a few older releases? Because this has no impacts to majority of ICU4J users, we might not want to bump ICU version - but how?

2. IncomingBugs / Review • reviewfeedback

{ab} - {bc} -> {ab} {ac} {az} {ba} {bc}, but not including {aa} {bd} -> does not work

{abc} - {abe} -> {abc} {abd} {abe}

{ab[c-d]}

{ab[c-d{Andy}]}

{abc} {abd} {abAndy}

http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%3Aemoji%3A 

2015/06/03

1. ICU4C trunk build

1. root cause of the TestNumberFormat was resolved - but why this suddenly showed up?
2. trunk memory leak - caused by UnicodeString change - Markus will resolve the issue.

2. Non-member swap (Markus)

1. Ok to move inside classes?
2. In-class “friend” definition, more compiler-friendly than definition outside class
3. See addendum email June 1 to “ICU4C API proposal: C++ move/swap LocalPointer & UnicodeString” on icu-design

3. ICU 56 GA date - agreed on following

1. CLDR - planned GA - Sep 15 (16?)
2. ICU 56 RC: Sep 23
3. ICU 56 GA: Oct 7

4. ICU data update

1. desired to import the latest structure change as soon as possible
2. for M1 (John / Peter?) - next 2-3 weeks

5. IncomingBugs

2015/05/27

1. ICU4C trunk build - intermittent failure

1. /tsformat/cnumtst/TestNumberFormat
2. since #11665 / r37448
3. UNUM_GROUPING_SIZE set by unum_setAttribute() might not be returned by unum_getAttribute() - either test case or getAttribute() should be changed (file a new ticket)
4. Andy suspect ctest_resetICU() / u_cleanup() does something with ICU globals - NumberFormat cache?

1. Michael to try commenting out ctest_restICU() to see if the problem is reproducible on the Solaris system.

2. API Proposals for ICU 56
3. Deprecate RBNF durations, and mention DurationFormat as its replacement? #10587 (George)

1. Look into MeasureFormat instead as the replacement.
2. Propose to icu-design and add to the API proposal document.

4. IncomingBugs

2015/05/20

1. Only Peter and myself, therefore, no meeting today.
2. ICU4C trunk build failure

   cnumtst  {

        TestNumberFormat   {

!!        Fail: error in setting and getting attributes for UNUM_GROUPING_SIZE

        } ---[1 ERRORS in /tsformat/cnumtst/TestNumberFormat]  (12ms)

2015/05/13

1. ICU Trac (Markus)

1. Obsolete fields (OS, Java Version, Version, Load): deleted values, Steven to remove fields
2. Maybe-obsolete tickets - steven to review, close

2. Policy for fixing a security bug (Yoshito)

1. notification
2. back level releases
3. sensitive flag ‘removal’ after fix?
4. closed tickets with sensitive=yes

3. API Proposals for ICU 56
4. IncomingBugs

2015/05/06  - cancelled due to UTC

2015/04/29

1. Unicode 8 in ICU (Markus)

1. Ticket #11574 → tools trunk, C & J branches; all tests pass
2. Want to get it into milestone 1
3. Ok to merge into trunk now, keep ticket open for final update after May UTC meeting?

2. trac:  “new” with owner moved to “accepted”. (Steven)
3. IncomingBugs ( new simpler query:  ‘status=new’ )
4. [quarterly question] Schedule during UTC next week?

2015/04/22

1. ICU 56m1

1. schedule - July 1 - confirmed
2. CLDR new structure / sync’ed

2. Trac (Markus & Steven)

1. Use & track status=reviewfeedback: “ball is back in the ticket owner’s court”

1. When a reviewer finishes review and looks good -

1. fix in branch - reviewfeedback with comment LGTM - and owner can merge into trunk and close the ticket as fixed
2. fix in trunk - reviewer LGTM: can directly close the ticket

2. Reviewer sets this for LGTM (so that the owner can merge into the trunk) or to request further changes – say in the notes what the owner should do

3. API Proposals for ICU 56 (DigitXxx proposals on hold for now)
4. IncomingBugs
5. A note on deprecation: Use of ULOC_REQUESTED_LOCALE with ucol_getLocaleByType has been deprecated since ICU 2.8 (2004). Recently ucol_getLocaleByType started returning an error for ULOC_REQUESTED_LOCALE. This broke some apps that used third-party Qt framework, which has a QtWebKit subframework (built against old ICU headers) that used this...

1. ICU 54 ticket #10477 “drop support for ULOC_REQUESTED_LOCALE”

2015/04/15

1. Schedule

1. Google no longer requests that fall 2015 release be moved earlier

2. (Travis Keep) We need to decide as a group how get/setPositivePrefix on DecimalFormat should work. I propose the following: https://docs.google.com/document/d/1BT0MtV3MY7s9rYq1BWIQdK9TWh61ridOCrZYz8YFKTg/edit

1. Mark: We should get to a new design for decimal formatting classes, and then map old API to new API
2. Travis: Have new classes in branch, but having trouble mapping old to new
3. getPositivePrefix() is @stable ICU 2.0, cannot change its behavior so significantly; should document its behavior more clearly, and design better new API
4. U+00A4 CURRENCY SIGN http://en.wikipedia.org/wiki/Currency_sign_%28typography%29
5. Bug in http://www.unicode.org/reports/tr35/tr35-numbers.html#Special_Pattern_Characters “If doubled, replaced by the international currency symbol (U+00A4).”

3. (Travis Keep) DecimalFormat::get/setCurrencyPluralInfo - This API has poor test coverage and seems completely broken. See http://bugs.icu-project.org/trac/ticket/11626. I would like to see this API removed because I don’t believe anybody could be using it effectively.

1. CurrencyPluralInfo - http://bugs.icu-project.org/trac/ticket/6433 - xji, 2008
2. Resolution:  take offline. Consider redesign, which may not include this class.

4. API Proposals for ICU 56
5. IncomingBugs

1. http://bugs.icu-project.org/trac/ticket/11635 

2015/04/08

1. ICU 56 planning

1. Milestone doc: 56.0.1 (m1)
2. CLDR fall release schedule is not yet decided
3. Any inputs for release date? Sep 30 or Oct 7?

1. Fall schedule is not critical for Apple, Apple wants spring release a little bit earlier (mid March)
2. Google: want both spring/fall release earlier / this fall : Sep 30 or 23?

4. 55 BRS

2. Collation demo - Michael updated to 55 last night
3. http://bugs.icu-project.org/trac/ticket/5456 
4. IncomingBugs
   

2015/04/01

1. ICU 55 release!

1. BRS
2. Download page
3. Michael to check ICU version used for demos on the ICU site. For example, refresh the http://demo.icu-project.org/icu-bin/collation.html index page. (r37302)
4. #11595 Locale Matcher - send back to review
5. active tickets with code on trunk
6. other open tickets for ICU 55.1, Yoshito will move to 56

2. Unicode conference proposed submissions from ICU project members

1. abstract deadline in two days: 2015-apr-03
2. http://www.unicodeconference.org/abstracts.htm
3. ICUers IUC 39 doc
4. All past conferences - http://www.unicode.org/conference/past-conf.html 

3. IncomingBugs

2015/03/25

(Peter away for this one)

1. CLDR ticket #8297, ICU ticket #11595 

1. CLDR data update - 27.0.1?
2. proposed to merge the changes if the change is confirmed in a branch (trunk?)
3. This is a regression because fallback data was defective & basically unused, but got fixed in CLDR 27 which makes ICU worse.
4. Mark/John will prepare the fix by end of Thursday / in a branch - if verified, merge it into 55 GA

2. BRS
3. Download page

1. Tickets fixed in ICU 55
2. note impact and/or benefits and/or migration issues - mark to put initial contents by end of Friday / other people add contents there on next week by Wed

4. IncomingBugs

2015/03/18

1. ICU 55 status

1. CLDR ticket#8288

1. Mark tried to fix it in CLDR
2. John tried the modified data imported to ICU - and it causes a few test failures in ICU
3. CLDR TC in this morning, we agreed following:

1. Revert the changes for CLDR 27
2. ICU 55 RC to use release-27-d05 (not including the changes for CLDR#8288)
3. Continue to investigate the issues / implication
4. If we identified the whole issue - what’s wrong / what need to be fixed, then we may publish the fix as CLDR 27.1. And if it is before ICU 55.1 release date, then we will integrate the fix. Otherwise, defer to ICU 55.1.1 (or 55.2).

2. BRS
3. Download page

2. Unicode conference proposed submissions from ICU project members
3. ICU demos link broken: clicking “ICU4C Demos” in home page sidebar produces:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, icuproj@icu-project.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Apache/2.2.17 (Fedora) Server at demo.icu-project.org Port 80

4. IncomingBugs

2015/03/11

1. ICU 55 code freeze

1. Today last commits for code review feedback

1. #11568 ok, Fredrik committing now
2. can still submit fixes for docs, BRS items

2. Reviews (srl’s done)
3. C++ @draft API promotions

1. Peter’s email “Draft ICU4C 55 API promotions, issues”
2. Spreadsheet

4. Java @draft API promotions

1. Yoshito’s email “ICU4J 55 API promotion draft”
2. Spreadsheet

5. BRS

2. IncomingBugs
3. Tickets with trunk code http://bugs.icu-project.org/trac/report/24 

2015/03/04

1. ICU 55 feature freeze

1. Trunk status

1. http://bugs.icu-project.org/trac/build/icu4c_trunk_memory_leak
2. intltest unable to open any test data text files – seems flaky now, may be environment issue, keep watching
3. http://bugs.icu-project.org/trac/build/icu4j-p-win flaky, div by 0 in Perl script

2. Last check-in (except for code review feedback/BRS tasks)

1. EOD today/Wednesday
2. Roll remaining tickets to 56 or UNSCHeduled

3. Reviews
4. BRS

1. script code update problems (Markus)

1. Support all (new) ISO script codes via enum UScriptCode  vs.  stable enum constant names that match Unicode script property value aliases
2. See email “ICU script code update problems” mar02, see recommendations at the end of Markus’ email
3. http://bugs.icu-project.org/trac/ticket/11561
4. Mark replied: I have never thought that any of the ISO script codes were of much (if any) value until they are in Unicode. So I'm all in favor of only putting them in when we need to.
5. Peter replied: I agree with your recommendations. I don’t think the constants are very useful significantly before the scripts are encoded.
6. Consensus: Now and in the future, add script codes only when they are encoded in Unicode (past version or known to go into next version). Markus will update UScriptCode API docs.

2. Try to get version numbers updated soon (helps with various other tasks)
3. Draft API promotion by end of this week, review in next week’s meeting

2. (Travis) - Avoid calling UnicodeString::append() in a loop in performance critical code. If you know ahead of time that you will be appending fewer than N UChars, it is much faster to stack allocate a UChar[N], write the UChars there and then append the entire array all at once with one call to UnicodeString::append.  I learned this the hard way.

1. Probably equally fast or better: getBuffer(minCapacity) – write into its buffer – releaseBuffer(new length)

3. (Travis) function template for deep copying optional pointer field within assignment operator?

1. new templatized ‘smart pointer’ class?
2. Travis will come up with more concrete proposal - revisit it later, after ICU 55

4. (Travis) Do we really want to have polymorphic cache keys in our unified cache? We had decided to support polymorphic keys about 1 year ago because that way we could store data under any type of key, not just locale. However, as best as I can tell the only type of cache key ever used is locale. Nobody is inventing their own key types yet.  Polymorphic keys do come at a price. My original cache design that used plain old char * as a key (which supports locale easily enough) took about 270ns for retrieval. Retrieving from the cache now takes 400-450ns. This extra time for cache retrieval can add up considering that to build a complicated object like DecimalFormat correctly will either require multiple cache retrievals or storing redundant data in the cache to avoid the multiple lookups.

1. Might need non-locale strings for Transliterator
2. Maybe do profiling to find out which piece makes “polymorphic” more expensive
3. Maybe limit polymorphism to fewer cases, only what we need (e.g., Locale-or-string)

5. API Proposals for ICU 55
6. IncomingBugs

2015/02/25

1. ICU server status? - mostly checkout failed

1. Longstanding ICU4C trunk data in ICU4J failure understood, due to RELATED_YEAR Calendar field addition in J, not C; there is a bug to remove from J (#11539)

2. Spoof / Confusable data update. Remove SL, SA, ML tables. (Andy & Mark)
   Ticket #11446
   Additional background information here: Document
3. Schedule - regular check-ins by next Wed (March 4) - are we ready?
4. API Proposals for ICU 55
5. 55 BRS task assignment

1. promotion candidates by end of next week - through ICU 53

6. IncomingBugs * Reviews

2015/02/18

1. Yoshito is out (in Japan)
2. ICU release schedule (Markus)

1. Would like to move future releases earlier by 2 weeks.
2. CLDR: OK starting spring 2016 release, may be too cramped for this fall
3. ICU: Ok to pull in starting with 2016 spring release as well, look more into fall release

3. Peter: Parameterized linebreak status - CLDR #4931, ICU #9379, proposal status

1. Ok to add all variants to ICU 55
2. Users who care about size will need to prune data
3. Peter to submit ticket for ICU 56 to support multiple types with smaller data: -> #11530
4. Andy idea: One set of rules for all types together, distinguish by rule status value
5. Andy: Important to get monkey test to work with new rules

1. Peter to submit another ticket for this: -> #11531

4. API Proposals for ICU 55 (none for this week)
5. IncomingBugs * Reviews
6. Buildbot failures

1. ibm-rh1 svn checkout failure - seems to have been restarted?
2. icu4j trunk, Mac/ibm-macx (-e) - system problems? Errors are strange, e.g.

1. Warning: (CoverageTest.java:186) coverage of com.ibm.icuimpl.CalendarAstronomer$2: java.lang.ClassNotFoundException: com.ibm.icuimpl.CalendarAstronomer$2
2. Error: (CoverageTest.java:217) Unsupported URL: jar:file:main/tests/translit/out/lib/icu4j-translit-tests.jar!/com/ibm/icu

3. memory leak- Michael will use C release ticket

7. Sourceforge mirror (Steven)

1. FYI - mirroring is off.

2015/02/11

1. A common library for managing plural variants (Travis Keep) See PluralMap design doc.

1. Add comments, take offline.

2. As per PMC request for ticket#11230 - C vs. J difference when parsing ' 9 9 ' in lenient mode (Scott)
   I tested C & J with various inputs. (English)
   C
   parsing[ 9 9 ] with pattern[###]                parsed as[9]
   parsing[9 9] with pattern[###]                parsed as[9]
   parsing[ 9 999 ] with pattern[###]                parsed as[9]
   parsing[9 999] with pattern[###]                parsed as[9]
   Java
   testing ICU…
   parsing[ 9 9 ] with pattern[###]                parsed as[99]
   parsing[9 9] with pattern[###]                parsed as[99]
   parsing[ 9 999 ] with pattern[###]                    parsed as[9999]
   parsing[9 999] with pattern[###]                parsed as[9999]
   testing JDK…
   parsing[ 9 9 ] with pattern[###]                number parse failure: Unparseable number: " 9 9 "
   parsing[9 9] with pattern[###]                parsed [9]
   parsing[ 9 999 ] with pattern[###]                number parse failure: Unparseable number: " 9 999 "
   parsing[9 999] with pattern[###]                parsed as[9]

1. Mark: Space is parsed as grouping separator if space or nbsp is one. Should behave like comma if that is a grouping separator. Test with comma too.
2. Mark:

1. Test “9 9”, “9 999”, “9,9”, “9,999”

1. In two locales: one that has , as grouping separator and space-like as grouping separator.
2. Test in both strict and lenient.
3. Test with grouping separator on and off.
4. Test in C, J, and JDK.

2. Mark’s expectations

1. Allow leading spaces always.
2. Allow trailing spaces in the APIs that don’t take a ParsePosition. - Yoshito believes that number format internally stops at trailing space, but not return any error as long as a part of input is consumed. => Scott to check
3. Don’t eat trailing spaces in the APIs that do take a ParsePosition.
4. Think that in strict mode we require grouping-separators to be in the right positions, but not in lenient. Need to test.

3. API Proposals for ICU 55
4. IncomingBugs * Reviews

2015/02/04

1. Likely a short meeting because of UTC; have ICU room (Crane) near UTC room (Bashir).

1. Peter: Won’t be able to participate in this ICU mtg due to UTC activity

2. Known discrepancies between JDK and ICU DecimalFormat (Travis). Do we still want to behave like the JDK when possible? Will fixing ICU DecimalFormat to behave like JDK when possible break our users? See the full details in the linked doc.  http://bugs.icu-project.org/trac/browser/icu4j/branches/tkeep/10458/main/tests/core/src/com/ibm/icu/dev/test/format/DataDrivenNumberFormatTestSuite.java
   http://bugs.icu-project.org/trac/browser/icu4j/branches/tkeep/10458/main/tests/core/src/com/ibm/icu/dev/test/format/NumberFormatTest.java
   
   
   

4. API Proposals for ICU 55
5. IncomingBugs

2015/01/28

1. UTC meeting next week - for now, as scheduled
2. API Proposals for ICU 55
3. IncomingBugs * Reviews
4. CLDR vs. ICU capitalization context

1. spreadsheet: Extracted Casing Info 

2015/01/21

1. ICU 55 RC/GA dates - agreed

1. 2014-03-04 (Wed): Final check-in for features/regular bug fixes (Feature Freeze)
2. 2014-03-09 (Mon): API change report updated for review (new APIs, status changes)
3. 2014-03-11 (Wed): Final check-in (response to code review, except some BRS items)
4. 2014-03-18 (Wed): ICU 55 RC
5. 2014-04-01 (Wed): ICU 55 GA

2. ICU4J CharsetProvider - canonical name issue

1. Original ticket: #11479 do not rely on Charset.forName() recursion detection
2. Test failure on Apple Java 6
3. Yoshito’s proposal : remove the code trying to use a same canonical name with JRE [see icu core list posting this morning]
4. Charset.name() (“Java canonical name”) must be the MIME-preferred name, or an IANA name, or else have an “x-” prefix.
5. Charset.equals(other): “Two charsets are equal if, and only if, they have the same canonical names.”
6. Scenario: Let’s say...

1. JDK has Charset C which implements MIME name “ISO-8859-2”.
2. ICU has Charset D which implements MIME name “ISO-8859-2” but with some mappings different from those in C.
3. ICU has Charset E which implements MIME name “ISO-8859-2” but with some mappings different from those in C and D.
4. C, D, and E must have different canonical names. What should D.name() and E.name() be?

1. Can CharsetICU have an extra method - #mimeName()?
2. Its .name() is already the MIME-preferred name, if there is one.

7. conclusion

1. ICU Charset implementation relies on preferred MIME name from our converter alias data (in ticket #11479)
2. Document ‘equals’ does not work when two or more different charset implementations are available with the same preferred MIME name (Markus submitted new ticket #11493)

3. IncomingBugs * Reviews

1. deleting spam that got through - please also update regexes at http://bugs.icu-project.org/trac/wiki/BadContent and delete-as-spam in http://bugs.icu-project.org/trac/admin/spamfilter/monitor (srl)

2015/01/14

1. Tool to ensure that closed tickets marked as fixed (as opposed to won’t fix, duplicate etc.) include changes to the trunk. Maybe trac can enforce this. (Travis)

1. one idea is that when a trunk commit happens, a field is updated in trac (setting the ‘has commits’ bit on). could be used for reports etc. srl
2. Some tickets close without trunk changes - docs, failed experiments, etc
3. -> after branch review, the ticket will be moved to review-feedback state

2. ICU4J 52 maintenance update for eclipse (Yoshito)

1. Korean word break fix [http://bugs.icu-project.org/trac/ticket/11466]
2. eclipse team wants it to be version 52.1.1
3. publish the version as ICU4J 52.1.1 also for non-eclipse users.
4. ICU4J 52.1.1 ticket 
5. -> Yoshito will post ICU4J 52.1.1 files and update the 52 download page later in this week.

3. ICU4C SimpleDateFormat malloc optimization [#11457] (Yoshito)

1. avoid malloc as much as possible [#11294] / matchString (case insensitive substring match, currently case folding in a copy - which triggers malloc), UnicodeString assignment in some timezone formatting code

1. Proposed fix in yoshito’s branch
2. Similar change in ICU 4.4 improved our client code’s performance about 20 times

1. DB2 query which triggers a lot of date formatting in a tight loop
2. DB2 overrides ICU malloc - because ICU does not provide thread local/global memory model distinction, their malloc locks global memory pool and affecting other theads.

2. A new issue [#11457] recently introduced

1. Fixed threading problem in SimpleDate::format()
2. Root cause: SimpleDateFormat mutate NumberFormat by setMaximumIntegerDigits / setMinimumIntegerDigits to format each numeric field. e.g. “y-MM-dd” (y: min=1, MM: min=2/max=2, dd: min=2/max=2)
3. Proposed solution (yoshito)

1. Create an internal simple subclass of NumberFormat supporting functionalities necessary for DateFormat’s use. (no currency, no grouping, etc.) - DateNumberFormat
2. DateNumberFormat implements a const format method taking minimum/maximum integer digits.
3. By default, SimpleDateFormat constructor creates a DateNumberFormat for a given locale unless it requires “complex” numbering system.
4. SimpleDateFormat::format() to check the type of NumberFormat at runtime. If it is a DateNumberFormat, using the format method taking mix/max digits for formatting numeric field (so you do not need to lock / clone a NumberFormat instance), otherwise, mutex-lock the NumberFormat instance / or clone per thread.
5. Consensus: Sounds good

4. API Proposals for ICU 55

1. Check date symbol enums C vs J - related year missing in J?

5. IncomingBugs * Reviews

2015/01/07

1. Collation (Markus)

1. Done: Normal Hiragana letters have common tertiary weights, small Hiragana have below-common weights in root.
2. Done: Script reordering reorders single scripts, not groups.
3. Windows build failure reported from unmodified toolutil.vcxproj?? http://bugs.icu-project.org/trac/build/icu4c-b-win/38126#step_build

1. #includes changed..  (Steven)

4. Copied download/55m1 page to download/55 and added script reordering.

2. API Proposals for ICU 55
3. IncomingBugs * Reviews

Past Meetings