At Fri, 14 Dec 2012 03:08:46 +0900, Fuminobu TAKEYAMA wrote:
Hello,
- ibus-* depending on ibus 1.5's typelib (developed in python) is
not compatible with 1.4. We must update "Requires" tag.
"not compatible" means it can't be built with 1.5, or it just needs a proper dependency?
Python is a dynamic language so we can see, for example, method missing error at runtime. latter one?
Looks so.
- Do we need to clean up its package's change log while it was
in the M17N/Devel project?
The change log must be incremental. You must not remove the old changelog that have been already checked in FACTORY, at least.
So we need to merge the changelog, maybe with a bit of clean up.
The package of ibus-1.5 have been separately developed in M17N/Devel and not been submitted to Factory.
It has several change log entries for ibus-1.4.99.x. I think changes from 1.4 to 1.5 is not clear from the log but it is not so problematic: https://build.opensuse.org/package/view_file?expand=1&file=ibus.changes&package=ibus&project=M17N%3ADevel # Oh, it is not linked to M17N/ibus...
Then, yes, let's clean up M17N:Devel changelog. The development history in M17N:Devel isn't that important in this case.
- The released version still have something wrong.
For example, Ctrl+Space is the only key to toggle IM state but I can see other keys in its dconf profile. (bug or dead code?)
That's bad. But maybe fixable during the development?
Maybe. We can add Zenkaku Hankaku key for Japanese by adding a file to /etc/dconf/profile but I don't know which binding is active. I'll try.
I think we should put all ibus-related packages into a clean sub-project and test them carefully before updating M17N/ibus.
Yes, let's put all ibus-related packages to M17N:Devel at first (just do branch or linkpac), then watch the build status.
Unfortunately, since we don't have any rules about M17N:Devel, it is not clean and has a lot of packages. # I cannot run zypper dup -r M17N:Devel
Shall we make a new subproject M17N:Testing like openSUSE:*:*:Testing for packages that should be merged into M17N soon?
I remember the similar topic raised up for mozc sometime ago in opensuse-ja ML :) I personally don't mind so much about creating a new sub project, but thinking twice, it doesn't have to be M17N:xxx at all but could be the personal one like home:yyy:ibus-test. What we need is a really a temporary test project that won't live long. Otherwise it'll be just the second M17N:Devel. (And basically testing here at this moment means checking mostly build breakage. The functional test is a different question.) If we care about the stability of M17N packages, it's the thing we need to reconsider. M17N project serves as the devel project of FACTORY, thus it should contain the latest packages to be merged to FACTORY. It conflicts with the development of new packages. In other words, if we'd like to keep stable packages, we should create the sub-project for that (e.g. M17N:stable), instead of creating yet another test sub-project.
Or clean up M17N:Devel?
Yes, this should be cleaned up in anyway, too. I think all scim updates should be merged to M17N / FACTORY sooner or later. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org