From is@sac.sfbay.sun.com Mon Feb 23 17:20:30 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1O1KTXR028742 for ; Mon, 23 Feb 2009 17:20:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1O1KP14026145; Tue, 24 Feb 2009 09:20:28 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFJ0080DQE22N00@brm-avmta-1.central.sun.com>; Mon, 23 Feb 2009 18:20:26 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFJ00DKPQE2C6E0@brm-avmta-1.central.sun.com>; Mon, 23 Feb 2009 18:20:26 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1O1KQhE007863; Mon, 23 Feb 2009 17:20:26 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1O1KORj028735; Mon, 23 Feb 2009 17:20:24 -0800 (PST) Received: (from is@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n1O1KOrP028731; Mon, 23 Feb 2009 17:20:24 -0800 (PST) Date: Mon, 23 Feb 2009 17:20:24 -0800 (PST) From: Ienup Sung Subject: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Message-id: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6609 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ICU 4.0.1 1.2. Name of Document Author/Supplier: Author: Rachel Zhang 1.3 Date of This Document: 23 February, 2009 4. Technical Description OVERVIEW International Components for Unicode (ICU) is a multi-platform, multi-locale, and MT-safe I18N API with C and C++ bindings. It comes from the ICU open source community at http://icu-project.org/. Currently, we deliver ICU version 3.2 [1] (which is the default) and ICU version 2.1 [2, 3] as Contracted Consolidation/Project Private interfaces. As the interface classifications imply, they are only for Sun internal product groups. Changing that going forward, this project proposes to deliver the new, ICU version 4.0.1 as the default ICU version and opening up the access to general public. (ICU 4.0.1 is a patch level revision to ICU 4.0 and fully compatible with ICU 4.0.) TECHNICAL DETAILS This project delivers ICU 4.0.1 as the default libraries, headers, and utilities as we did for [1]. Existing ICU 2.1 and ICU 3.2 libraries will still be delivered until the support for each is no longer required by the contracted SWI product groups. (At that time, we will appropriately EOF the older versions of libraries as needed.) For the SWI products that will use ICU 4.0.1 in future, we will forward- port a few selected Sun enhancements such as code conversion name aliases being used and supported in SWI products such as webmail that originated from libNLS which was replaced by ICU 2.1 several years ago. We will try to minimize such "enhancements" as bare minimum going forward since we hope the ICU deliverables to be "pass-through" as much as possible in future. SWI product groups are okay with this project as outlined in this material. Due to the known C++ ABI issues documented in the [3, 9, 10, 11] and also based on the currently available resources, the project team plans to deliver a single set of ICU 4.0.1 libraries that is compatible and linkable with C++ binaries compiled with Sun C++ 5.1 or later only. (In other words, no GNU GCC compiler compatible sets are planned at this point.) This dependency will be documented in the [4]. The existing SUNWicu and SUNWicud packages will be used to deliver the ICU 4.0.1. The man pages will be delivered via Solaris Nevada man gate and the section 8 man pages may change into the section 1M man pages if necessary and/or required by the man page group. INTERFACE STABILITY The project exports the following interfaces. While there are some level of stability described at the ICU open source community web site on the ICU C and C++ interfaces, when we apply Sun standard, they are rather of Volatile in nature and thus we hope to ask for Volatile stability for the interfaces shown at below: Interface Stability Comment --------- --------- ------- /usr/lib/libicudata.so.40.1 Volatile ICU library [4] /usr/lib/libicui18n.so.40.1 Volatile ICU library [4] /usr/lib/libicuio.so.40.1 Volatile ICU library [4] /usr/lib/libicule.so.40.1 Volatile ICU library [4] /usr/lib/libiculx.so.40.1 Volatile ICU library [4] /usr/lib/libicutu.so.40.1 Volatile ICU library [4] /usr/lib/libicuuc.so.40.1 Volatile ICU library [4] /usr/include/layout/*.h Volatile ICU headers /usr/include/unicode/*.h Volatile ICU headers /usr/lib/icu/4.0.1/Makefile.inc Volatile Makefile.inc for ICU apps /usr/bin/derb Volatile ICU utility [5] /usr/bin/genbrk Volatile ICU utility [5] /usr/bin/gencnval Volatile ICU utility [5] /usr/bin/genrb Volatile ICU utility [5] /usr/bin/icu-config Volatile ICU utility [5] /usr/bin/makeconv Volatile ICU utility [5] /usr/bin/pkgdata Volatile ICU utility [5] /usr/bin/uconv Volatile ICU utility [5] /usr/sbin/genccode Volatile ICU utility [5] /usr/sbin/gencmn Volatile ICU utility [5] /usr/sbin/gensprep Volatile ICU utility [5] /usr/sbin/genuca Volatile ICU utility [5] /usr/sbin/icuswap Volatile ICU utility [5] For the ICU libraries, we also ask the same interface stability for the corresponding 64-bit libraries. The project imports the following interfaces: Interface Stability Comment --------- --------- ------- libc Committed C runtime library libCrun Committed C++ runtime library libm Committed Math. library libpthread Committed POSIX thread library RELEASE BINDING The project team asks for Micro/Patch release binding. REFERENCES [1] PSARC/2005/041 ICU 3.2 [2] PSARC/2002/699 ICU utilities [3] PSARC/2002/348 International Components for Unicode (ICU) [4] Section 3LIB library man pages at the materials directory of the case: materials/{ libicudata.3lib, libicui18n.3lib, libicuio.3lib, libicule.3lib, libiculx.3lib, libicuuc.3lib, libicutu.3lib } [5] Utility man pages at the materials directory of the case: { derb.1, genbrk.1, gencnval.1, genrb.1, icu-config.1, makeconv.1, pkgdata.1, uconv.1, genccode.8, gencmn.8, gensprep.8, genuca.8, icuswap.8 } [6] ICU 4.0/4.0.1 User Guide: http://www.icu-project.org/userguide Available also at the materials directory of the case: materials/icu-4_0-userguide.zip [7] ICU 4.0.1 API Reference: http://www.icu-project.org/apiref/icu4c/ Available also at the materials directory of the case: materials/icu4c-4_0_1-docs.zip [8] OSR #2736 International Components for Unicode (ICU) v. 3.2 and later [9] LSARC/1993/571 LSARC Guidelines for C++ [10] LSARC/1997/150 C++ 5.0 [11] LSARC/2000/211 C++ 5.1 [12] PSARC/2008/549 Apache Standard C++ Library [13] LSARC/2008/776 GNU Developer Collection [14] LSARC/2009/017 Sun Studio C/C++/dbx Collection 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: G11N 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Nicolas.Williams@sun.com Tue Feb 24 08:39:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OGdIWO024826 for ; Tue, 24 Feb 2009 08:39:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1OGdAsj009372 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Feb 2009 00:39:17 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFK0074BWXGUR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 09:39:16 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFK00MXNWXE27A0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 09:39:15 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1OGUG3s006446; Tue, 24 Feb 2009 10:30:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1OGUGrE006445; Tue, 24 Feb 2009 10:30:16 -0600 (CST) Date: Tue, 24 Feb 2009 10:30:16 -0600 From: Nicolas Williams Subject: Re: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224163015.GM9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 592 On Mon, Feb 23, 2009 at 05:20:24PM -0800, Ienup Sung wrote: > INTERFACE STABILITY > > The project exports the following interfaces. While there are some level of > stability described at the ICU open source community web site on the ICU > C and C++ interfaces, when we apply Sun standard, they are rather of Volatile > in nature and thus we hope to ask for Volatile stability for the interfaces > shown at below: So everything Volatile. If the actual interfaces really are so volatile, might it not make sense to go for multiple versions being installed, each being Uncommitted? Nico -- From Ienup.Sung@sun.com Tue Feb 24 11:03:35 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OJ3YtQ002584 for ; Tue, 24 Feb 2009 11:03:35 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1OJ3WK9002873 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Feb 2009 03:03:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00C0F3LWTC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:03:32 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL009L13LV8D70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:03:31 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1OJ3V6O019029 for ; Tue, 24 Feb 2009 11:03:31 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL00F0026LVQ00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:03:31 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.19.84]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL0038N3LJCM90@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:03:24 -0800 (PST) Date: Tue, 24 Feb 2009 11:02:11 -0800 From: Ienup Sung Subject: Re: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224163015.GM9992@Sun.COM> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <49A44433.1080404@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 593 Nicolas Williams wrote at 02/24/09 08:30: > So everything Volatile. If the actual interfaces really are so > volatile, might it not make sense to go for multiple versions being > installed, each being Uncommitted? Trouble is that with Uncommitted as you know incompatible change can happen only at minor release including EOF. Furthermore, it is possible with ICU that their patch level release (i.e., ICU 4.0 vs. ICU 4.0.1 and not Sun's Patch release binding) occupies the same name space in terms of versioning and yet could contain incompatibility. I believe Volatile is the one. Ienup From Nicolas.Williams@sun.com Tue Feb 24 11:29:14 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OJTDBQ002968 for ; Tue, 24 Feb 2009 11:29:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1OJSl1k051115; Tue, 24 Feb 2009 12:29:12 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00E0F4SN2P00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 11:29:11 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL009WY4SM8J70@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 11:29:11 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1OJKCDY006651; Tue, 24 Feb 2009 13:20:12 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1OJKCik006650; Tue, 24 Feb 2009 13:20:12 -0600 (CST) Date: Tue, 24 Feb 2009 13:20:12 -0600 From: Nicolas Williams Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <49A44433.1080404@sun.com> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224192011.GT9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 917 On Tue, Feb 24, 2009 at 11:02:11AM -0800, Ienup Sung wrote: > Nicolas Williams wrote at 02/24/09 08:30: > >So everything Volatile. If the actual interfaces really are so > >volatile, might it not make sense to go for multiple versions being > >installed, each being Uncommitted? > > Trouble is that with Uncommitted as you know incompatible change can happen > only at minor release including EOF. Furthermore, it is possible with ICU That's why I suggested multiple versions. > that their patch level release (i.e., ICU 4.0 vs. ICU 4.0.1 and not Sun's > Patch release binding) occupies the same name space in terms of versioning > and yet could contain incompatibility. That would be a problem, but does that actually happen? Do they really break compatbility on patch? I haven't followed the ICU community, but I have a hard time believing that. Can you point to specific instances where they've done this? From Ienup.Sung@Sun.COM Tue Feb 24 11:48:57 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OJmv8n003414 for ; Tue, 24 Feb 2009 11:48:57 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1OJmrYR064631 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 24 Feb 2009 12:48:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00E1R5PKZF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:48:56 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL009GL5PI8J90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:48:54 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1OJmsKk024946 for ; Tue, 24 Feb 2009 11:48:54 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL00E004ZNFZ00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:48:54 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.19.84]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL00L3Q5P2ZNC0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 11:48:38 -0800 (PST) Date: Tue, 24 Feb 2009 11:47:30 -0800 From: Ienup Sung Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224192011.GT9992@Sun.COM> Sender: Ienup.Sung@Sun.COM To: PSARC-ext@Sun.COM Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@Sun.COM Message-id: <49A44ED2.3060807@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 1337 Nicolas Williams wrote at 02/24/09 11:20: > On Tue, Feb 24, 2009 at 11:02:11AM -0800, Ienup Sung wrote: >> Nicolas Williams wrote at 02/24/09 08:30: >>> So everything Volatile. If the actual interfaces really are so >>> volatile, might it not make sense to go for multiple versions being >>> installed, each being Uncommitted? >> Trouble is that with Uncommitted as you know incompatible change can happen >> only at minor release including EOF. Furthermore, it is possible with ICU > > That's why I suggested multiple versions. FWIW, we are already doing so, i.e., we already deliver ICU 2.1 and 3.2 together and now trying 4.0.1. >> that their patch level release (i.e., ICU 4.0 vs. ICU 4.0.1 and not Sun's >> Patch release binding) occupies the same name space in terms of versioning >> and yet could contain incompatibility. > > That would be a problem, but does that actually happen? Do they really > break compatbility on patch? I haven't followed the ICU community, but > I have a hard time believing that. > > Can you point to specific instances where they've done this? Yes, between ICU 3.8 and 3.8.1, date formatting and parsing has changed in ways that may require re-coding of user programs. Please see Known Issues, Bugs and Patches section of the following: http://icu-project.org/download/3.8.html#ICU4C Ienup From Nicolas.Williams@sun.com Tue Feb 24 11:58:38 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OJwbAX003775 for ; Tue, 24 Feb 2009 11:58:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1OJwUnY006594; Wed, 25 Feb 2009 03:58:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL0030565L2400@brm-avmta-1.central.sun.com>; Tue, 24 Feb 2009 12:58:33 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL00DSP65L6YC0@brm-avmta-1.central.sun.com>; Tue, 24 Feb 2009 12:58:33 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1OJnY0R006703; Tue, 24 Feb 2009 13:49:34 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1OJnYiV006702; Tue, 24 Feb 2009 13:49:34 -0600 (CST) Date: Tue, 24 Feb 2009 13:49:34 -0600 From: Nicolas Williams Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224192011.GT9992@Sun.COM> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224194934.GX9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 5227 I looked at what the user guide has to say about compatibility and it looks like we could even safely go with Committed for the C and Java interfaces. For C++ the claim is that "C++ binary compatibility is not supported is primarily because the design of C++ language and runtime environments present extreme technical difficulties to doing so. Stable C++ APIs are source compatible, but applications using them must be recompiled when moving between ICU releases." Select quotes and links below. I strongly recommend Uncomitted for the Java and C interfaces, and Volatile for the C++ interfaces. Nico - http://icu-project.org/userguide/design.html#Version_Numbers "For ICU releases and the library (code) versions, a change in the minor version number indicates releases that may have feature additions or may break binary compatibility, such as between version 2.0 and 2.2. A change only in milli (or micro) version numbers indicates a maintenance release that is binary compatible. For example, ICU 2.6.2 was a maintenance release which was binary compatible with ICU 2.6 and ICU 2.6.1. (See below for more information on ICU Binary Compatibility .) ICU reference releases are denoted by even minor version numbers (like ICU 1.6 or 3.4). Previously, odd minor version numbers (like ICU 1.7) were used for “enhancement” releases. Currently, odd numbers are used only for unreleased unstable snapshot versions." - The policy on source compatibility is described here: http://icu-project.org/userguide/design.html#ICU_API_compatibility And it looks quite compatible with ICU being Uncommitted in Solaris. - http://icu-project.org/userguide/design.html#ICU_Binary_Compatibility "ICU4C may be configured for use as a system library in an environment where applications that are built with one version of ICU must continue to run without change with later versions of the ICU shared library. Here are the requirements for enabling binary compatibility for ICU4C: 1. Applications must use only APIs that are marked as stable. 2. Applications must use only plain C APIs, never C++. 3. ICU must be built with function renaming disabled. 4. Applications must be built using an ICU that was configured for binary compatibility. 5. Use ICU version 3.0 or later. Stable APIs Only. APIs in the ICU library that are tagged as being stable will be maintained in future versions of the library. Stable functions will continue to exist with the same signature and the same meaning, allowing applications to continue to work without change. Stable APIs do not guarantee that the results from every function will always be completely identical between ICU versions . Bugs may be fixed. The Unicode character data may change with new versions of the Unicode standard. Locale data may be updated or changed, yielding different results for operations like formatting or collation. Applications that require exact bit-for-bit, bug-for-bug compatibility of ICU results should not rely on ICU release-to-release binary compatibility, but should instead link against a specific version of ICU. To verify that an application uses only stable APIs, build it with the C preprocessor symbols U_HIDE_DRAFT_API and U_HIDE_DEPRECATED_API defined. This will produce build errors if any draft, deprecated or obsolete APIs are used. C APIs only. Only plain C APIs remain compatible across ICU releases. The reason C++ binary compatibility is not supported is primarily because the design of C++ language and runtime environments present extreme technical difficulties to doing so. Stable C++ APIs are source compatible, but applications using them must be recompiled when moving between ICU releases. Function renaming disabled. Function renaming is an ICU feature that allows an application to explicitly link against a specific version of the ICU library, and to continue to use that version even when other ICU versions exist in the runtime environment. This is the exact opposite of release-to-release binary compatibility – instead of being able to transparently change ICU versions, an application is explicitly tied to one specific version. Function renaming is enabled by default, and must be disabled at ICU build time to enable release to release binary compatibility. To disable renaming, use the configure option configure -–disable-renaming [other configure options] (Configure options may also be passed to the runConfigureICU script.) To enable release-to-release binary compatibility, ICU must be built with --disable-renaming, and applications must be built using the headers and libraries that resulted from the –-disable-renaming ICU build ICU Version 3.0 or Later. Binary compatibility of ICU releases is supported beginning with ICU version 3.0. Older versions of ICU (2.8 and earlier) do not provide for binary compatibility between versions. " - There's also a data compatibility section: http://icu-project.org/userguide/design.html#ICU_Data_Compatibility From Nicolas.Williams@sun.com Tue Feb 24 12:09:26 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OK9PcW022006 for ; Tue, 24 Feb 2009 12:09:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1OK9C0i022704; Tue, 24 Feb 2009 20:09:22 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL001016NH7E00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Feb 2009 12:09:17 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL00E8U6NHRY60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Feb 2009 12:09:17 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1OK0EoM006712; Tue, 24 Feb 2009 14:00:14 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1OK0E1j006711; Tue, 24 Feb 2009 14:00:14 -0600 (CST) Date: Tue, 24 Feb 2009 14:00:14 -0600 From: Nicolas Williams Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <49A44ED2.3060807@sun.com> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224200014.GY9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <49A44ED2.3060807@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 896 On Tue, Feb 24, 2009 at 11:47:30AM -0800, Ienup Sung wrote: > >Can you point to specific instances where they've done this? > > Yes, between ICU 3.8 and 3.8.1, date formatting and parsing has changed in > ways that may require re-coding of user programs. Please see Known Issues, > Bugs and Patches section of the following: > > http://icu-project.org/download/3.8.html#ICU4C Thanks. That seems like a very isolated issue. I don't see any other such issues noted in the releases of ICU4C versions 3.2.1, 3.4.1, 3.6 or 4.0.1. The actual readmes don't mention any other backwards incompatible changes either. As far as I can tell there's no reason that we couldn't ship multiple versions of ICU if we had to as the result of an unfortunate backwards- incompatible change. Therefore I don't see why we couldn't ship ICU 4.0.1 as Uncommitted for C and Java (and Volatile for C++). Nico -- From Ienup.Sung@sun.com Tue Feb 24 12:14:12 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OKECeY024698 for ; Tue, 24 Feb 2009 12:14:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1OKE6cm019280 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 24 Feb 2009 12:14:12 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL0011R6VNXP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:14:11 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL00ER96VLS150@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:14:09 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1OKE9Rd027975 for ; Tue, 24 Feb 2009 12:14:09 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL004006RMI800@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:14:09 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.19.84]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL00B4J6VHJY50@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:14:06 -0800 (PST) Date: Tue, 24 Feb 2009 12:12:57 -0800 From: Ienup Sung Subject: Re: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224194934.GX9992@Sun.COM> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <49A454C9.7010206@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 6096 The thing is, in the past, they even changed C interface return value types between releases. The formating breakage that I mentioned is also for C interfaces. Clearly there is no way we can treat ICU as of now as Committed or even Uncommitted of Sun's unless what they trying to achieve recently is actually and clearly demonstrated for many releases to come. And then in a future release integration, we can promote the interface stability. BUT not now. We, with a vendor cap on this time, should deliver what it is as it is and we have a responsibility to inform that to customers. Ienup Nicolas Williams wrote at 02/24/09 11:49: > I looked at what the user guide has to say about compatibility and it > looks like we could even safely go with Committed for the C and Java > interfaces. > > For C++ the claim is that "C++ binary compatibility is not supported is > primarily because the design of C++ language and runtime environments > present extreme technical difficulties to doing so. Stable C++ APIs are > source compatible, but applications using them must be recompiled when > moving between ICU releases." > > Select quotes and links below. > > I strongly recommend Uncomitted for the Java and C interfaces, and > Volatile for the C++ interfaces. > > Nico > > > - http://icu-project.org/userguide/design.html#Version_Numbers > > "For ICU releases and the library (code) versions, a change in the > minor version number indicates releases that may have feature > additions or may break binary compatibility, such as between version > 2.0 and 2.2. A change only in milli (or micro) version numbers > indicates a maintenance release that is binary compatible. For > example, ICU 2.6.2 was a maintenance release which was binary > compatible with ICU 2.6 and ICU 2.6.1. (See below for more > information on ICU Binary Compatibility .) > > ICU reference releases are denoted by even minor version numbers > (like ICU 1.6 or 3.4). Previously, odd minor version numbers (like > ICU 1.7) were used for “enhancement” releases. Currently, odd numbers > are used only for unreleased unstable snapshot versions." > > - The policy on source compatibility is described here: > > http://icu-project.org/userguide/design.html#ICU_API_compatibility > > And it looks quite compatible with ICU being Uncommitted in Solaris. > > - http://icu-project.org/userguide/design.html#ICU_Binary_Compatibility > > "ICU4C may be configured for use as a system library in an environment > where applications that are built with one version of ICU must > continue to run without change with later versions of the ICU shared > library. > > Here are the requirements for enabling binary compatibility for ICU4C: > > 1. Applications must use only APIs that are marked as stable. > 2. Applications must use only plain C APIs, never C++. > 3. ICU must be built with function renaming disabled. > 4. Applications must be built using an ICU that was configured for > binary compatibility. > 5. Use ICU version 3.0 or later. > > Stable APIs Only. APIs in the ICU library that are tagged as being > stable will be maintained in future versions of the library. Stable > functions will continue to exist with the same signature and the same > meaning, allowing applications to continue to work without change. > > Stable APIs do not guarantee that the results from every function > will always be completely identical between ICU versions . Bugs may > be fixed. The Unicode character data may change with new versions of > the Unicode standard. Locale data may be updated or changed, yielding > different results for operations like formatting or collation. > Applications that require exact bit-for-bit, bug-for-bug > compatibility of ICU results should not rely on ICU > release-to-release binary compatibility, but should instead link > against a specific version of ICU. > > To verify that an application uses only stable APIs, build it with > the C preprocessor symbols U_HIDE_DRAFT_API and U_HIDE_DEPRECATED_API > defined. This will produce build errors if any draft, deprecated or > obsolete APIs are used. > > C APIs only. Only plain C APIs remain compatible across ICU releases. > The reason C++ binary compatibility is not supported is primarily > because the design of C++ language and runtime environments present > extreme technical difficulties to doing so. Stable C++ APIs are > source compatible, but applications using them must be recompiled > when moving between ICU releases. > > Function renaming disabled. Function renaming is an ICU feature that > allows an application to explicitly link against a specific version > of the ICU library, and to continue to use that version even when > other ICU versions exist in the runtime environment. This is the > exact opposite of release-to-release binary compatibility – instead > of being able to transparently change ICU versions, an application is > explicitly tied to one specific version. > > Function renaming is enabled by default, and must be disabled at ICU > build time to enable release to release binary compatibility. To > disable renaming, use the configure option > > configure -–disable-renaming [other configure options] > > (Configure options may also be passed to the runConfigureICU > script.) > > To enable release-to-release binary compatibility, ICU must be built > with --disable-renaming, and applications must be built using the > headers and libraries that resulted from the –-disable-renaming ICU > build > > ICU Version 3.0 or Later. Binary compatibility of ICU releases is > supported beginning with ICU version 3.0. Older versions of ICU (2.8 > and earlier) do not provide for binary compatibility between > versions. > " > > - There's also a data compatibility section: > > http://icu-project.org/userguide/design.html#ICU_Data_Compatibility > From Ienup.Sung@sun.com Tue Feb 24 12:23:31 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OKNUR6024977 for ; Tue, 24 Feb 2009 12:23:31 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1OKNRbk002646 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 24 Feb 2009 20:23:29 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00G0P7B4OR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:23:28 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL009M57B48KE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:23:28 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1OKNSv6029070 for ; Tue, 24 Feb 2009 12:23:28 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL004006RMI800@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:23:28 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.19.84]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL00BI57ANJY90@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:23:12 -0800 (PST) Date: Tue, 24 Feb 2009 12:22:03 -0800 From: Ienup Sung Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224200014.GY9992@Sun.COM> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <49A456EB.2040204@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <49A44ED2.3060807@sun.com> <20090224200014.GY9992@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 1246 It is not an isolated issue unless you are the core maintainer who has absolute authority and can give your word that you'll match Sun's interface stability with ICU going forward. And for the reasons I mentioned in the previous email, I assert ICU 4.0.1 should be Volatile. Ienup Nicolas Williams wrote at 02/24/09 12:00: > On Tue, Feb 24, 2009 at 11:47:30AM -0800, Ienup Sung wrote: >>> Can you point to specific instances where they've done this? >> Yes, between ICU 3.8 and 3.8.1, date formatting and parsing has changed in >> ways that may require re-coding of user programs. Please see Known Issues, >> Bugs and Patches section of the following: >> >> http://icu-project.org/download/3.8.html#ICU4C > > Thanks. That seems like a very isolated issue. I don't see any other > such issues noted in the releases of ICU4C versions 3.2.1, 3.4.1, 3.6 or > 4.0.1. The actual readmes don't mention any other backwards > incompatible changes either. > > As far as I can tell there's no reason that we couldn't ship multiple > versions of ICU if we had to as the result of an unfortunate backwards- > incompatible change. Therefore I don't see why we couldn't ship ICU > 4.0.1 as Uncommitted for C and Java (and Volatile for C++). > > Nico From Nicolas.Williams@sun.com Tue Feb 24 12:27:55 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OKRsHl025039 for ; Tue, 24 Feb 2009 12:27:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1OKRnww005567; Tue, 24 Feb 2009 20:27:51 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00G017IEXP00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 12:27:50 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL009G67IE8BD0@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 12:27:50 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1OKIp6t006761; Tue, 24 Feb 2009 14:18:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1OKIpYL006760; Tue, 24 Feb 2009 14:18:51 -0600 (CST) Date: Tue, 24 Feb 2009 14:18:51 -0600 From: Nicolas Williams Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <49A454C9.7010206@sun.com> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224201850.GF9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 902 On Tue, Feb 24, 2009 at 12:12:57PM -0800, Ienup Sung wrote: > The thing is, in the past, they even changed C interface return value > types between releases. > > The formating breakage that I mentioned is also for C interfaces. > > Clearly there is no way we can treat ICU as of now as Committed or > even Uncommitted of Sun's unless what they trying to achieve recently > is actually and clearly demonstrated for many releases to come. > > And then in a future release integration, we can promote the interface > stability. BUT not now. > > We, with a vendor cap on this time, should deliver what it is as it is > and we have a responsibility to inform that to customers. I'll let an ARC member decide whether this issue is significant. IMO ICU is important, and it's important that there be at least one version that is guaranteed to be on the system for the life of a minor release. Nico -- From Ienup.Sung@sun.com Tue Feb 24 12:45:27 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OKjRn2025485 for ; Tue, 24 Feb 2009 12:45:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1OKjNKv031179 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 24 Feb 2009 13:45:27 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL007098BQXU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:45:26 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL00EQO8BPRS80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:45:25 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1OKjPmO015267 for ; Tue, 24 Feb 2009 12:45:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL00H007PLB000@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:45:25 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.19.84]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL002MT8BL8530@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 12:45:22 -0800 (PST) Date: Tue, 24 Feb 2009 12:44:13 -0800 From: Ienup Sung Subject: Re: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224201850.GF9992@Sun.COM> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <49A45C1D.4000201@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> <20090224201850.GF9992@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 1100 We've been delivering ICU 2.1 and 3.2 for several minor releases now. Clearly way more than a life time of a minor release. We don't EOF off things that easily unless that is absolutely necessary. In fact, I anticipate that we will have to deliver more in the future. Since, as an example, if a SWI team uses ICU 4.0 and another SWI team wants to use say, ICU 5.0 which has a new feature, then we will definitely want to deliver and maintain the both. Also don't get the Volatile as a message that we want to and will switch ICU 4.0.1 with ICU 5.0 within a life time of minor release or anything like that. Volatile means that when we have ICU 4.0.2, i.e., ICU 4.0.1 patched, say, at S11U2, customers be aware that you *might* see changes in interfaces however unlikely that will be and that is the key message. Ienup Nicolas Williams wrote at 02/24/09 12:18: > I'll let an ARC member decide whether this issue is significant. > > IMO ICU is important, and it's important that there be at least one > version that is guaranteed to be on the system for the life of a minor > release. > > Nico From Nicolas.Williams@sun.com Tue Feb 24 14:56:58 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1OMuvHF029132 for ; Tue, 24 Feb 2009 14:56:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1OMuoMc020692; Wed, 25 Feb 2009 06:56:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00A05EET8Q00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Feb 2009 14:56:53 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL005I0EESH810@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Feb 2009 14:56:52 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1OMltu2007048; Tue, 24 Feb 2009 16:47:55 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1OMltRW007047; Tue, 24 Feb 2009 16:47:55 -0600 (CST) Date: Tue, 24 Feb 2009 16:47:55 -0600 From: Nicolas Williams Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <49A45C1D.4000201@sun.com> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224224754.GW9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> <20090224201850.GF9992@Sun.COM> <49A45C1D.4000201@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1325 On Tue, Feb 24, 2009 at 12:44:13PM -0800, Ienup Sung wrote: > We've been delivering ICU 2.1 and 3.2 for several minor releases now. > Clearly way more than a life time of a minor release. > > We don't EOF off things that easily unless that is absolutely necessary. So you won't remove ICU 2.1 and 3.2 from the system? > In fact, I anticipate that we will have to deliver more in the future. > Since, as an example, if a SWI team uses ICU 4.0 and another SWI team wants > to > use say, ICU 5.0 which has a new feature, then we will definitely want to > deliver and maintain the both. OK, that's one part of what I was asking for (multiple versions if needed). > Also don't get the Volatile as a message that we want to and will > switch ICU 4.0.1 with ICU 5.0 within a life time of minor release or > anything like that. > > Volatile means that when we have ICU 4.0.2, i.e., ICU 4.0.1 patched, say, > at S11U2, customers be aware that you *might* see changes in interfaces > however unlikely that will be and that is the key message. You've shown that some incompatible changes were made at minor releases, but what about patch? Do you have any examples of incompatible changes made in patch releases? The ICU user guide clearly claims that the ICU community intends not to break anything on patch (except for C++). From Nicolas.Williams@sun.com Tue Feb 24 15:33:09 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ONX9gX000636 for ; Tue, 24 Feb 2009 15:33:09 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1ONX4ZH007886; Tue, 24 Feb 2009 16:33:08 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00H19G386Y00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Feb 2009 15:33:08 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL0055FG37H660@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Feb 2009 15:33:07 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1ONO9UO007178; Tue, 24 Feb 2009 17:24:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1ONO98D007177; Tue, 24 Feb 2009 17:24:09 -0600 (CST) Date: Tue, 24 Feb 2009 17:24:09 -0600 From: Nicolas Williams Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224224754.GW9992@Sun.COM> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224232409.GC9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> <20090224201850.GF9992@Sun.COM> <49A45C1D.4000201@sun.com> <20090224224754.GW9992@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 796 On Tue, Feb 24, 2009 at 04:47:55PM -0600, Nicolas Williams wrote: > On Tue, Feb 24, 2009 at 12:44:13PM -0800, Ienup Sung wrote: > > In fact, I anticipate that we will have to deliver more in the future. > > Since, as an example, if a SWI team uses ICU 4.0 and another SWI team wants > > to > > use say, ICU 5.0 which has a new feature, then we will definitely want to > > deliver and maintain the both. > > OK, that's one part of what I was asking for (multiple versions if > needed). I think that's good enough for me, actually, because I don't think ICU will break on patch releases, and if it does we're "off the hook" if we claimed Volatile. That's lame, but perhaps the best we can do without dedicating additional resources to handle ICU patches. So, I'm happy now. Thanks, Nico -- From Ienup.Sung@sun.com Tue Feb 24 15:52:25 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ONqOPw001377 for ; Tue, 24 Feb 2009 15:52:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1ONqN8g017240 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 24 Feb 2009 16:52:24 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00L0PGZB4Q00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 15:52:23 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL005IMGZAH850@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 15:52:23 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1ONqMle024553 for ; Tue, 24 Feb 2009 15:52:22 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFL00400GXYLC00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 15:52:22 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.19.84]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFL0013ZGYHKJ10@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 24 Feb 2009 15:51:54 -0800 (PST) Date: Tue, 24 Feb 2009 15:50:45 -0800 From: Ienup Sung Subject: Re: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224224754.GW9992@Sun.COM> Sender: Ienup.Sung@sun.com To: PSARC-ext@sun.com Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@sun.com Message-id: <49A487D5.5090407@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> <20090224201850.GF9992@Sun.COM> <49A45C1D.4000201@sun.com> <20090224224754.GW9992@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 1378 Nicolas Williams wrote at 02/24/09 14:47: > So you won't remove ICU 2.1 and 3.2 from the system? They are Contracted interfaces. By definition of the interface stability, unless SWI product teams, i.e., CONSUMERS, no longer need them, there is no way we can remove them. We can remove them iff CONSUMERS no longer need them and after following the EOF process. > OK, that's one part of what I was asking for (multiple versions if > needed). As I said, we already have and deliver multiple versions of ICU 2.1 and 3.2 to Solaris. It is clearly also explained in the spec of this case: This project delivers ICU 4.0.1 as the default libraries, headers, and utilities as we did for [1]. Existing ICU 2.1 and ICU 3.2 libraries will still be delivered until the support for each is no longer required by the contracted SWI product groups. (At that time, we will appropriately EOF the older versions of libraries as needed.) > You've shown that some incompatible changes were made at minor releases, > but what about patch? Do you have any examples of incompatible changes > made in patch releases? The ICU user guide clearly claims that the ICU > community intends not to break anything on patch (except for C++). The example that I gave was on their patch release of ICU 3.8.1 not at their minor release. (Please read "their" as of ICU's.) Ienup From Nicolas.Williams@sun.com Tue Feb 24 16:08:21 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1P08K80013004 for ; Tue, 24 Feb 2009 16:08:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1P08AQn029789; Wed, 25 Feb 2009 08:08:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFL00607HPSGH00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 16:08:16 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFL002SWHPQ3D40@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Feb 2009 16:08:14 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1ONxGAU007237; Tue, 24 Feb 2009 17:59:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1ONxGFL007236; Tue, 24 Feb 2009 17:59:16 -0600 (CST) Date: Tue, 24 Feb 2009 17:59:16 -0600 From: Nicolas Williams Subject: Re: [i18n-discuss] ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <49A487D5.5090407@sun.com> To: Ienup Sung Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <20090224235916.GJ9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> <20090224201850.GF9992@Sun.COM> <49A45C1D.4000201@sun.com> <20090224224754.GW9992@Sun.COM> <49A487D5.5090407@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 256 On Tue, Feb 24, 2009 at 03:50:45PM -0800, Ienup Sung wrote: > The example that I gave was on their patch release of ICU 3.8.1 not at > their minor release. (Please read "their" as of ICU's.) Ah, I was confused because I did not see any 3.8 release notes. From Ienup.Sung@Sun.COM Wed Feb 25 10:23:48 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PINm5k013469 for ; Wed, 25 Feb 2009 10:23:48 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1PINlq8012667 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Feb 2009 11:23:48 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM00K0PWFNX100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 11:23:47 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM008RJWFN5NB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 11:23:47 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1PINk8h000701 for ; Wed, 25 Feb 2009 10:23:46 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFM00G00VKKML00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 10:23:46 -0800 (PST) Received: from [192.168.1.93] ([unknown] [129.150.20.135]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFM005PTWFLK4D0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 10:23:46 -0800 (PST) Date: Wed, 25 Feb 2009 10:22:35 -0800 From: Ienup Sung Subject: Re: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <20090224235916.GJ9992@Sun.COM> Sender: Ienup.Sung@Sun.COM To: PSARC-ext@Sun.COM Cc: i18n-discuss@opensolaris.org Reply-to: Ienup.Sung@Sun.COM Message-id: <49A58C6B.8020404@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> <20090224201850.GF9992@Sun.COM> <49A45C1D.4000201@sun.com> <20090224224754.GW9992@Sun.COM> <49A487D5.5090407@sun.com> <20090224235916.GJ9992@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Status: RO Content-Length: 63 This case was approved at today's PSARC review meeting. Ienup From carlsonj@phorcys.east.sun.com Wed Feb 25 10:36:48 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PIam62014209 for ; Wed, 25 Feb 2009 10:36:48 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1PIafrR003557; Wed, 25 Feb 2009 18:36:45 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM00941X195P00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 10:36:45 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM009POX17Z7A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 10:36:43 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1PIT1iU014105; Wed, 25 Feb 2009 13:29:01 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1PIT1Sp014102; Wed, 25 Feb 2009 13:29:01 -0500 (EST) Date: Wed, 25 Feb 2009 13:29:01 -0500 From: James Carlson Subject: Re: ICU 4.0.1 [PSARC/2009/129 FastTrack timeout 03/02/2009] In-reply-to: <49A58C6B.8020404@sun.com> To: Ienup.Sung@sun.com Cc: PSARC-ext@sun.com, i18n-discuss@opensolaris.org Message-id: <18853.36333.64411.137927@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902240120.n1O1KOrP028731@sac.sfbay.sun.com> <20090224163015.GM9992@Sun.COM> <49A44433.1080404@sun.com> <20090224192011.GT9992@Sun.COM> <20090224194934.GX9992@Sun.COM> <49A454C9.7010206@sun.com> <20090224201850.GF9992@Sun.COM> <49A45C1D.4000201@sun.com> <20090224224754.GW9992@Sun.COM> <49A487D5.5090407@sun.com> <20090224235916.GJ9992@Sun.COM> <49A58C6B.8020404@sun.com> Status: RO Content-Length: 336 Ienup Sung writes: > This case was approved at today's PSARC review meeting. I gave a +1 to it in the meeting. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677