Re: Re: A patch added to mozc by submit-request 114205

On Wed, Apr 18, 2012 at 4:47 PM, Marguerite Su <[email protected]> wrote:
> On Wed, Apr 18, 2012 at 4:14 PM, Takashi Iwai <[email protected]> wrote:
>> At Wed, 18 Apr 2012 15:03:04 +0800,
>> Weng Xuetian wrote:
>>>
>>> On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su <[email protected]> wrote:
>>> > 2012/4/18 Fuminobu TAKEYAMA <[email protected]>:
>>> >> Hi, Marguerite Su and M17N maintainers,
>>> >>
>>> >> I am confused by the big patch for Fcitx added to the mozc package yesterday
>>> >> without any reviews and discussion.
>>> >>
>>> >> https://build.opensuse.org/request/show/114205
>>> >>
>>> >>
>>> >
>>> > Hi, ftake,
>>> >
>>> > yes, I don't why either, when I created the request, no reviewer is
>>> > automatically added.
>>> >
>>> > only me, and I have no review option but to accept.
>>> >
>>> >> My concern is that this patch decrease maintainability of that package.
>>> >>
>>> >> As you know, Mozc's release cycle is very short.
>>> >> Who will maintain the patch?
>>> >> Will Fcitx maintainers (including the patch developer?) release new patch
>>> >> for every Mozc release?
>>> >> I cannot think they will do so, as long as I read their website.
>>> >
>>> > Fcitx developers and maintainers will do.
>>> >
>>> > I think you just see http://code.google.com/p/fcitx/download. actually
>>> > it's their "release" website. fcitx-mozc is fast developed at
>>> > https://github.com/fcitx/fcitx-mozc
>>> >
>>> >>
>>> >> This is why the openSUSE packaging policy says "Ask upstream first", right?
>>> >>
>>> >>
>>> >
>>> > absolutely right, but this time it's Fcitx upstream developers that
>>> > asked me to add so.
>>> >
>>> >
>>> >> It is, however, good news that fcitx support Mozc.
>>> >> I guess this can be demonstrated by creating separated OBS package like
>>> >> fcitx-mozc if some header files of mozc are packaged.
>>> >>
>>> >
>>> > yes, I'm glad to say Mozc users have a third input method to taste.
>>> >
>>> > it's not possible I have to say. you know how Mozc is developed and
>>> > packaged. there's actually no such header file. fcitx in M17N has many
>>> > derivatives, and it has a not-released-yet fcitx-anthy in
>>> > home:opensuse_zh. if it could be done that way, it would already be
>>> > done. I bcc-ed fcitx core developer, and he'll explain that tech thing
>>> > in detail.
>>> >
>>> >>
>>> >> Anyway, I would like to roll back for now because mozc is now really essential
>>> >> package for Japanese users.
>>> >> If the patch is the best solution and users need fcitx support,
>>> >> shall we add the patch again?
>>> >>
>>> >
>>> > Fcitx-mozc is also essential for some group of fcitx Japanese users. I
>>> > think as packagers we have no obvious reason to drop a successful and
>>> > well-maintained feature. by adding it, fcitx OBS maintainers will also
>>> > have to maintain mozc, there're 4 active maintainers on OBS,
>>> > personally I think it's good to add maintianers to such a essential
>>> > package.
>>> >
>>> > openSUSE is the best distro that fcitx supports. fcitx developers are
>>> > also on OBS( home:csslayer:fcitx* ). so there's no need to worry the
>>> > unmaintained thing that early. it really hurts someone's feeling.
>>> >
>>> >> --
>>> >> Fuminobu TAKEYAMA
>>>
>>> Hi,
>>> I'm one of the fcitx developer.
>>>
>>> For your question:
>>> Yes, fcitx will release new patch against every new mozc release, it's
>>> supported by fcitx upstream.
>>>
>>> There is several reason that I can't and don't want to make fcitx-mozc upstream.
>>> 1. mozc is not open developed, though it's open source.
>>> 2. different release schedule might be conflict with each other, the
>>> best solution from my point of view is develop outside mozc.
>>> 3. mozc will not become a standalone library in near future (Though I
>>> tried to ask them to do so).
>>>
>>> For the patch, it only adds new file, and will not break any existing things.
>>>
>>> For other distribution, debian and fedora, also include uim-mozc,
>>> which is not mozc upstream too. Add fcitx-mozc for debian is also on
>>> the way. They also use the patch in order to get uim compiled, that's
>>> another reason that I choose to release patch.
>>>
>>> For potential users, I don't want to talk about this too much, but
>>> there are request on Fcitx issue list, for adding Japanese support,
>>> and anthy development it is said that have moved to mozc, and mozc it
>>> much more easy to develop (Even must use some special buildsystem).
>>
>> OK, so judging from you and Marguerite's comments, we can take the
>> patch as is for now.  But I suggest to makes easier to strip it off,
>> e.g. via %if %with_fcitx or such.  Could you resubmit the package in
>> that way?
>>
>
> I'll try. (because I'm not familiar with conditional builds...
>
>> Also, at the next time, please announce or ask on m17n (or
>> opensuse-factory) ML before doing non-trivial updates like this.
>> Otherwise it'll surprise people unexpectedly.
>>
>> Basically osc submitreq review is the last step, not the first nor the
>> sole step for integration.  If a new feature is added or a feature is
>> changed, it should be announced to users publicly on ML beforehand.
>
> it's my fault. I don't even know there's a m17n ML before today.
>
>>
>>
>> thanks,
>>
>> Takashi

done and I dragged you two into reviewers
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]