It looks like this stuff is coming together, but I'd like to propose for
now promoting this to a regular fast track. I don't see anything
intrinsically wrong here, and the case will almost certainly be approved
on Wednesday. Having it be a fast track gives me a warm fuzzy knowing
that the details are properly handled here at ARC before the underlying
code is delivered into any consolidation.
Either one of you can change the case to a fast track. Please set the
time out for Thursday if you like; its shorter than the norm for a fast
track, but if things look like they haven't gelled properly on Wednesday
we can ask for more time at that point.
(And as I said, I'd be rather surprised at this point if we don't get
the administrivia here dealt with properly by then.)
-- Garrett
Alan Hargreaves wrote:
> Another option that you have, if we are talking about delivering into
> the same consolidation may also be instead of contracting the
> interfaces, use this case to extend the original to include the new
> code that needs the library. This would make some sense given that the
> one group is looking after everything here.
>
> alan.
>
> Alan Hargreaves wrote:
>> Excellent. That makes the contract easy and the case much simpler. I
>> would suggest leave the stability of libchewing as it is. Fill out
>> the contract form and place a copy in the directory of this case (as
>> well as the email I think).
>>
>> Other PSARC folks, have I missed anything here?
>>
>> alan.
>>
>> Yong Sun wrote:
>>> Hi, Alan,
>>>
>>> We (G11N input-method engineer team) are actually the people who
>>> maintaining the solaris porting of libchewing, scim-chewing, and
>>> iiimf-twle-chewing (we also developed this one). :)
>>>
>>> Regards,
>>>
>>> Alan Hargreaves wrote:
>>>> All that having a contract means is that within the developer
>>>> groups working on these two projects for Solaris/OpenSolaris there
>>>> is an agreement that if a change is to be made to the library that
>>>> the scim people will be notified.
>>>>
>>>> This looks a lot closer to what you actually want.
>>>>
>>>> alan.
>>>>
>>>> Yong Sun wrote:
>>>>> No, I don't intend to promote it to committed, probably
>>>>> uncommitted is fine.
>>>>>
>>>>> I attached all API changes (in diff format), most of them are
>>>>> about initialization, configuration, and candidate iterating. And
>>>>> some interfaces are removed (or moved to internal private), like
>>>>> char/utf8_char utilities, user_phrase manipulating, zuin/pinyin
>>>>> utilities.
>>>>>
>>>>> And libchewing, scim-chewing, iiimf-twle-chewing are all community
>>>>> opensource softwares. I don't know if we need/could have a
>>>>> contract for them.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Alan Hargreaves wrote:
>>>>>> So, if I read the prior cases correctly, you are promoting
>>>>>> libchewing form Project/Private to something else (Committed?)
>>>>>> and we do have some incompatible changes to interfaces.
>>>>>>
>>>>>> Can you perhaps outline what the incompatible changes are?
>>>>>>
>>>>>> Might it be a better idea to leave the stability of libchewing as
>>>>>> it currently is (Project/Private under the old stability system)
>>>>>> and have contract scim-chewing take out a contract?
>>>>>>
>>>>>> My feeling is that if you want to raise the stability, this case
>>>>>> should probably be promoted to a fast track.
>>>>>>
>>>>>> Regards,
>>>>>> Alan Hargreaves
>>>>>>
>>>>>>
>>>>>> Yong Sun wrote:
>>>>>>> Hi, Alan, Garrett,
>>>>>>>
>>>>>>> Thanks for reviewing.
>>>>>>>
>>>>>>> The initial integration of libchewing is covered in
>>>>>>> PSARC/2005/525, as a project private interface, located in
>>>>>>> /usr/lib/iiim. And when scim is integrated (covered in
>>>>>>> PSARC/2008/418), libchewing is required both by scim-chewing and
>>>>>>> iiimf-twle-chewing, so it's moved to /usr/lib.
>>>>>>>
>>>>>>> Currently, there is no other client applications depends on
>>>>>>> libchewing, besides scim-chewing and iiimf-twle-chewing.
>>>>>>>
>>>>>>> Here is the release announcement for version 0.3.2, which lists
>>>>>>> the what's new,
>>>>>>> http://groups.google.com/group/chewing/browse_thread/thread/0067e04c8ea29ff3,
>>>>>>>
>>>>>>> please read the bottom half for the English version.
>>>>>>>
>>>>>>> And yes, I only require a minor binding. I will update the case
>>>>>>> material to include this info.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Alan Hargreaves wrote:
>>>>>>>> I am concerned that this update breaks compatibility, yet is
>>>>>>>> being done as a self review. Are there any other consumers of
>>>>>>>> this library that could potentially be broken by this update?
>>>>>>>> If so, how will this be dealt with?
>>>>>>>>
>>>>>>>> What binding are you looking for? As I only see
>>>>>>>> nevada/opensolaris mentioned, I am assuming minor.
>>>>>>>>
>>>>>>>> Can you mention the case number which contains the prior
>>>>>>>> interfaces/bindings?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alan Hargreaves
>>>>>>>>
>>>>>>>>
>>>>>>>> Yong Young Sun wrote:
>>>>>>>>> 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:
>>>>>>>>> Update libchewing from 0.3.0 to 0.3.2
>>>>>>>>> 1.2. Name of Document Author/Supplier:
>>>>>>>>> Author: Yong Sun
>>>>>>>>> 1.3 Date of This Document:
>>>>>>>>> 27 July, 2009
>>>>>>>>>
>>>>>>>>> 4. Technical Description
>>>>>>>>>
>>>>>>>>> libchewing is a popular library for Traditional Chinese
>>>>>>>>> input method engine
>>>>>>>>> licensed in LGPLv2.1. And there are some input methods, like
>>>>>>>>> iiimf-twle-chewing, scim-chewing depends on this library
>>>>>>>>> to provide input
>>>>>>>>> services to users.
>>>>>>>>>
>>>>>>>>> The version currently shipped in nevada/opensolaris is
>>>>>>>>> 0.3.0, while the
>>>>>>>>> community recently released a newer version, 0.3.2. In
>>>>>>>>> this new release,
>>>>>>>>> the API/ABI compatiblities were broken, and some new
>>>>>>>>> features are added.
>>>>>>>>>
>>>>>>>>> iiimf-twle-chewing and scim-chewing had been updated to
>>>>>>>>> work with 0.3.2,
>>>>>>>>> we therefore need to deliver the updated version to
>>>>>>>>> nevada/opensolaris.
>>>>>>>>>
>>>>>>>>> The interfaces (header files and shared library) remain
>>>>>>>>> the same as
>>>>>>>>> before.
>>>>>>>>>
>>>>>>>>> 6. Resources and Schedule
>>>>>>>>> 6.4. Steering Committee requested information
>>>>>>>>> 6.4.1. Consolidation C-team Name:
>>>>>>>>> Globalization
>>>>>>>>> 6.5. ARC review type: Automatic
>>>>>>>>> 6.6. ARC Exposure: open
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
