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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Asia Pacific/Emerging Markets Sun Microsystems
