Now I'd request to remove m17n-db-japanese optional in input-methods and japanese-support group. Once the removal is done, I'd also request to update m17n-db/devel/m17n-db.spec not to remove ja-anthy for my testing. I think ja-tcode and ja-trycode are difficult for most users to be understand the usage. The main problem is that users might misunderstand the feature is the bug, i.e. not to show the lookup window. Another concern is that I wonder which ibus-anthy icon and ja-tcode icon gives users the default ja IM when they install all RPMs in CD/DVD. Since I think the tcode/trycode users are minority, I think it's better to disable the installation from CD/DVD at present. Then if the users fully understand the features of tcode/trycode, they could download the rpms via network with yum by manual. If a user require to exist tcode/trycode in CD/DVD, we will consider this again. However I think ibus-anthy fulfill the basic operation and the network RPMs could satisfy the minority users.
I don't see what exactly you are requesting for, and I'm opposed to this suggestion - the optional packages won't be in any ISOs unless it's specified in the kickstart file to compose. in fact, it's not in the Beta ISO nor the Beta Live. also dropping the package from the package group will misses a easy way to find out. (In reply to comment #0) > The main problem is that users might misunderstand the feature is the bug, i.e. > not to show the lookup window. IMHO ibus-m17n should be improved to see what DB currently is using etc and clearly make difference to others if any features gets confused. > Another concern is that I wonder which ibus-anthy icon and ja-tcode icon gives > users the default ja IM when they install all RPMs in CD/DVD. That would be better having different icons each other rather than removing the packages from comps. > Since I think the tcode/trycode users are minority, I think it's better to > disable the installation from CD/DVD at present. The package won't be installed by default for most users but is installed by the request of the certain users. Those sounds not a good reason to drop.
(In reply to comment #1) > IMHO ibus-m17n should be improved to see what DB currently is using etc and > clearly make difference to others if any features gets confused. Who improve it? If you have a patch, I can review it. Otherwise I would give a miss usage.
(In reply to comment #2) > (In reply to comment #1) > > IMHO ibus-m17n should be improved to see what DB currently is using etc and > > clearly make difference to others if any features gets confused. > > Who improve it? > If you have a patch, I can review it. > > Otherwise I would give a miss usage. file a rfe for that.
(In reply to comment #1) > file a rfe for that. So it would be done after the removal is done. > The package won't be installed by default for most users but is installed by > the request of the certain users. Actually I don't see any problems the minority users download the RPMs from network while ibus-anthy is available. The problem is that it could introduce a wrong appearances into ibus-anthy at present/in the future but it's out of the control since I don't manage the integration, I don't test the integration, I don't review any code changes at the moment. > Those sounds not a good reason to drop. I don't think so at present. The request can avoid the confusions unless the volunteers work on the module with the proper integrations/patches. I have never noticed the git changes of m17n-db-japanese. If yourself sometimes use t-code/trycode, it would make sense since it would be good that one of our engineers often checks it. It would be risk vs DVD/CD existence.
I'm not sure if the cultures are different here. I think the module integration in community and managing RPMs in each distributor are different situations. It's ok to add modules in each community if the community maintainers give the approvals. But if we integrate the RPMs into our distributions, I think the codes should be reviewed by the distribution before the integration is proceeded. It's not special for me to put RPMs on network for minority users, which are completely managed by external community and our distributions/engineers don't check/use RPMs. But is it special for Red Hat people if you argue this case :)? If you strongly like to maintain t-code/trycode in CD/DVD, I'd suggest you have the check the module per each release and if it's ok, probably it makes sense for me. On the other hand, probably network RPM is not big problem for the minority users. Thoughts?
(In reply to comment #4) > It would be risk vs DVD/CD existence. I'd say again, no m17n-db-japanese package is available in any ISOs. it won't be installed unless you explicitly select it from the list. comps just provides the metadata what the purpose the package is for.
(In reply to comment #6) > I'd say again, no m17n-db-japanese package is available in any ISOs. it won't > be installed unless you explicitly select it from the list. comps just provides > the metadata what the purpose the package is for. I don't get your mention at all. Please talk off line next time before you comment those. Since all the optional RPMs doesn't exist in CD/DVD and they are put in network, probably current status is ok. Also it seems yum groupinstall doesn't install the optional RPMs as I heard. Now it's ok if m17n-db anthy can be installed with RPM from network. Closing this.