[opensuse-m17n] A patch added to mozc by submit-request 114205
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 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. This is why the openSUSE packaging policy says "Ask upstream first", right? 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. 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? -- Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 18 Apr 2012 14:07:43 +0900, Fuminobu TAKEYAMA wrote:
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
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.
This is why the openSUSE packaging policy says "Ask upstream first", right?
Yes, exactly. The right process would be to merge fcitx support to the mozc upstream. Was the patch submitted to mozc at all? If not, let's do it first.
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.
Hm, let's see whether this is feasible. It's a backend-integration part, thus it includes lots of internal headers. It might be that we'll end up with packaging all internal headers into mozc-devel package or such...
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?
Basically it's permitted to keep patches in the package, too. But this is only when the patches are properly maintained and carried forward with the version update, etc. An option at this time is to allow the conditional build of mozc with or without fcitx. If the update breaks the fcitx patch, then simply disable fcitx. That is, the version update has a higher priority than the internal patch. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
2012/4/18 Fuminobu TAKEYAMA <ftake@geeko.jp>:
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.
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 -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su <i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA <ftake@geeko.jp>:
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.
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). -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 18 Apr 2012 15:03:04 +0800, Weng Xuetian wrote:
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su <i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA <ftake@geeko.jp>:
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.
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? 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. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, Apr 18, 2012 at 4:14 PM, Takashi Iwai <tiwai@suse.de> wrote:
At Wed, 18 Apr 2012 15:03:04 +0800, Weng Xuetian wrote:
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su <i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA <ftake@geeko.jp>:
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.
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
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, Apr 18, 2012 at 4:47 PM, Marguerite Su <i@marguerite.su> wrote:
On Wed, Apr 18, 2012 at 4:14 PM, Takashi Iwai <tiwai@suse.de> wrote:
At Wed, 18 Apr 2012 15:03:04 +0800, Weng Xuetian wrote:
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su <i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA <ftake@geeko.jp>:
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.
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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 18 Apr 2012 18:38:26 +0800, Marguerite Su wrote:
On Wed, Apr 18, 2012 at 4:47 PM, Marguerite Su <i@marguerite.su> wrote:
On Wed, Apr 18, 2012 at 4:14 PM, Takashi Iwai <tiwai@suse.de> wrote:
At Wed, 18 Apr 2012 15:03:04 +0800, Weng Xuetian wrote:
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su <i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA <ftake@geeko.jp>:
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.
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
Thanks. But please add chnagelog properly instead of modifying the existing entry. It's not good to modify the already published changelog entry. Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Weng Xuetian wrote:
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su<i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA<ftake@geeko.jp>:
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.
One thing I concern is, whether you fcitx guys have tested / will test the patched mozc packages in combination with ibus as well or not. If not, testing phase might be needed before release, because most Japanese users use mozc in combination with ibus ATM.
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.
You are right. IIRC, mozc developers only consist of Google employees and they won't adopt any patches from third parties.
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).
I'm also using mozc and think it is the best IM for Japanese users now. However, I haven't been so positive about making mozc default IM engine for Japanese due to above things.
For the patch, it only adds new file, and will not break any existing things.
Then, let's test whether the patched packages will work well or not even with ibus and scim anyway.
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).
Thanks for your efforts. Best, -- _/_/ Satoru Matsumoto - openSUSE Member - Japan _/_/ _/_/ Marketing/Weekly News/openFATE Screening Team _/_/ _/_/ mail: helios_reds_at_gmx.net / irc: HeliosReds _/_/ _/_/ http://blog.zaq.ne.jp/opensuse/ _/_/ -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 18 Apr 2012 17:40:40 +0900, Satoru Matsumoto wrote:
Weng Xuetian wrote:
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su<i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA<ftake@geeko.jp>:
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.
One thing I concern is, whether you fcitx guys have tested / will test the patched mozc packages in combination with ibus as well or not. If not, testing phase might be needed before release, because most Japanese users use mozc in combination with ibus ATM.
Looking at the patch, I guess it would rarely influence on other backends, but yes, it's a good point. More test coverages would be better. In general, you can use freely M17N:Devel subproject for such a testing purpose. Ask people testing packages on M17N:Devel, at least for regression tests, then move up to M17N. This is a safer procedure. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi all, Thank you for your comments and submission. Takashi Iwai wrote:
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.
OK, I see. Weng Xuetian wrote:
Yes, fcitx will release new patch against every new mozc release, it's supported by fcitx upstream.
I'll check the fcitx website before updating the package. Marguerite Su wrote:
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.
but please do not publish an untested package. I usually try to test for more than a week in daily use. It is fragile package and its upstream release sometimes contains experimental features. Since there are no openSUSE's official mozc package, many people install mozc and ibus-mozc from M17N repository. Takashi Iwai wrote:
Hm, let's see whether this is feasible. It's a backend-integration part, thus it includes lots of internal headers. It might be that we'll end up with packaging all internal headers into mozc-devel package or such...
I think it is frontend like ibus-mozc or mozc_emacs_helper rather than backend-integration. I have not read the headers in detail but the binaries created by the sources added by the patch seems to be linked to the common static libraries for mozc client. They might be implemented modularly. Weng Xuetian wrote:
3. mozc will not become a standalone library in near future (Though I tried to ask them to do so).
This one? http://code.google.com/p/mozc/issues/detail?id=124 I guess the maintainer did not understand what you want to do and benefits to the upstream unfortunately. # Even if he did, the answer might be same.
For other distribution, debian and fedora, also include uim-mozc, which is not mozc upstream too.
I could not find uim-mozc in Fedora. http://pkgs.fedoraproject.org/gitweb/?p=mozc.git Best regards, Fuminobu TAKEYAMA (2012/04/18 17:48), Takashi Iwai wrote:
At Wed, 18 Apr 2012 17:40:40 +0900, Satoru Matsumoto wrote:
Weng Xuetian wrote:
On Wed, Apr 18, 2012 at 2:30 PM, Marguerite Su<i@marguerite.su> wrote:
2012/4/18 Fuminobu TAKEYAMA<ftake@geeko.jp>:
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.
One thing I concern is, whether you fcitx guys have tested / will test the patched mozc packages in combination with ibus as well or not. If not, testing phase might be needed before release, because most Japanese users use mozc in combination with ibus ATM.
Looking at the patch, I guess it would rarely influence on other backends, but yes, it's a good point. More test coverages would be better.
In general, you can use freely M17N:Devel subproject for such a testing purpose. Ask people testing packages on M17N:Devel, at least for regression tests, then move up to M17N. This is a safer procedure.
thanks,
Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
participants (5)
-
Fuminobu TAKEYAMA -
Marguerite Su -
Satoru Matsumoto -
Takashi Iwai -
Weng Xuetian