武山です みなさん、ご意見ありがとうございます。 不安な点を取り除くのと問題点を整理しながら、 1つずつ答えていこうと思います。 昔と状況が少し変わって来ている部分もありますので、 開発プロセスの情報を共有できればいいかなと思います。 なんだかんだ1年くらい?しか開発に参加していないので、 間違っている箇所などなどがあれば、どうぞ指摘して下さい。 すみませんが、かなり量が多いので、引用がごちゃ混ぜになってしましました。 文脈が分かりにくい場合は、面倒かもしれませんが前後のメールもチェックして下さい。 ■M17N に置かれているパッケージはどうなる→無くならない

メインリポジトリに置いた場合、 以前開発チームで日本語パッケージを担当しておられたMikeさんでしたっけ？、 のような方がいらっしゃらない以上、不具合が出たとしても対応が遅くなってしまうと感じます。

松本さんのメールの途中に飛びますが:

M17N からは外してしまうのかどうか、ということを考えなければい けなくなりませんかね。

OBS のパッケージの開発では、今まで通り M17N のリポジトリにもパッケージが 置かれます。このリポジトリから（本来は）安定している版を定期的に Factory に送り、 最終的に DVD を含むメインリポジトリにも収録されます。 M17N リポジトリでの不具合修正は従来通りできますので、この点は心配ないと思います。

Mozcは絶対にないと困るパッケージである以上 不具合が出た場合に、少しでも対応がとられるのが望ましいと感じます。 自分は開発できないのですが、先日も直ぐにFIXして頂いており、大変安心できます。

前の Mozc が使えなくなったバグの原因は 同居している IBus の更新でしたので、 メインリポジトリに置くことでも M17N の下の隔離リポジトリに置くことでも 回避できました。 今回のような依存するパッケージによる問題の場合は、メインリポジトリに置くことで より原因を潰すのに効果があると思います。 # メンテナンスコストを気にしなければ両方の手段を取るのが良いですね ■Factory に行ったパッケージはどうメンテされるのか

メインに入るとなると、ディストリビューションリリース後はメンテナン ス & セキュリティアップデートのみが Update に上げられるだけで、基本的に はバージョンの更新はなしということになると思います。

最近は、upstream のマイナーアップデートをそのまま openSUSE の修正として配信 するケースが見られますが、Firefox などを除いては保守的な更新のみになるでしょう。 もし、最新のアップデートを使いたければ OBS の開発プロジェクト（Mozc は M17N）に行って バックポートされたパッケージをインストールするのが OBS のやり方では無いでしょうか？ 鎌田さんのメールに少し補足です:

不具合があれば誰にでも(基本的にはFactoryに submitした人(=武山さん?)が中心となって)修正できるはずです。

Factory への submit は M17N のメンテナー権限を持っている人なら誰でもできます。 変更履歴を見てもらえれば分かりますが、メンテしているのは私だけではありません。 # パッケージを修正して request することは誰でもできます。 もしメインリポジトリに不具合が残ったままのパッケージが入ってしまった場合には 修正を配布することになります。修正の request を出す権限はどうなっているかはちょっと 自信がありません。（誰でも出せる気がしますが…どなたか知りませんか？） ■日本の openSUSE ユーザーの現状 最初の corei5-koyama さんのメールに戻って:

現時点では、OpenSUSEを入れて、日本語で使うユーザーの殆どが、このMLを参考にするように 思えますので、

バグの対処方法などの情報の広がり方を見ていると、 最近では、見ていない人が多いのではないかと不安に感じているのですが、 皆さんどう思いますか？ # ML 離れが、OSS コミュニティ全体で起きている？ ■Mozc の開発体制によるリスク これが悩みの種なわけです。 松本さんが持つ懸念に別の見方もあるのではないかなと思いましたので:

以前開発者の話を聞いたことがあるんですが、開発チーム (= Google 社員) 以外の者が何らかの修正を希望するなら、自然言語で「こうして欲しい」と要望を 出してくれ、と言ってました。

自分もこういうやりとりを何度か Mozc の issue 管理システムで見ました。 逆に、自然言語で要望を出すと、それなりに対応してくれていると感じています。 # なぜコードを取り込まないのか？の理由は分からないわけですが、 # コードの著作権をしっかり社内で持っておきたいというのがありそうです。

- 各ディストリビューションでパッケージングする際にちょっとした修正が必要 となった場合、パッチ投げても取り込んでもらえないので、それぞれがパッ ケージングの際にパッチ当てるような形になっていく - 当然、Mozc 開発チームはそれぞれのディストリビューションでどんなパッチ 当てているか知らずに開発を進める - アップストリーム (Mozc 開発チーム) によって更新された部分と各ディスト リビューションで独自に当てているパッチ部分とでコンフリクト等が起こり、 問題が発生してしまう

現にこの問題は既に起きています。 ただ他の OSS プロジェクトでも良くある問題で、仮に平均的な他のプロジェクト同様に コードを取り込むようになったとしても、起きるのでは無いかと思います。 fcitx-mozc や uim-mozc のような機能拡張を取り込んでもらえないのは、 やはり問題です。

Mozc を採用するにはディストリビューション側にそういったことをケアできる メンテナーがいるかどうかが重要で

ということで、Mozc に限らず、色々考えて動作するようにするのが パッケージメンテナーの主な仕事なのかもしれません。

- ただ、上記のようなリスクがあるので、ちゃんとメンテナーが定まらないよう ならデフォルト IME にすること、ましてや、その結果として代替となりうる Anthy などが外されてしまったりすることになったら危険だと思う (ある日突 然日本語入力ができなくなったりしたら致命的すぎる)

その通りだと思います。 一方、Anthy のリスクも考えなければいけません。既に成熟しているのと仕組み上、 例えば scim のような問題にはなりにくいかと思いますが、 ML も1年半以上放置されています（最後のメールのパッチは取り込まれてない？）。 # Fedora には openSUSE にも入っていないパッチがさらにいくつか… 万が一セキュリティホールなどが見つかった場合は、SF のメンテナーに登録している 方々が対処してくれるのではないかと信じてはいますが…さてどうでしょう？ SKK と Canna があることにはありますが、Mozc と両方入れておくというのが より良いのでは？と考えています。 ■混ぜるな危険

日本語 (正確には多言語) 関連のソフトを「メインだけ」で揃えるのは事実上不 可能だと思うので、openSUSE インストール後多くの人が M17N をインストール ソースとして追加することになるでしょうが、その時にメインにあるものと M17N にあるものとでバージョンが異なり、IBus 他の連携するソフトとの間で問 題が起こる可能性がありそうな気がします。「混ぜるな危険」状態になってしま わないかな…と。

みなさん、M17N からどのパッケージを入れていますか？ 私自身は普通ではないので、IBus だけではなく、fcitx や fontconfig も 入れていますが。 一応、Mozc を使いたい場合は Mozc だけを M17N からインストールして、 IBus はメインリポジトリのものをそのまま使うようにと案内しているので、 Mozc だけの人も多いのでは？と予想しています。 リポジトリの優先度による問題もあるので、 今の M17N を基本的に追加してもらう形はあまり好ましくないのではないでしょうか？ # もちろん、隔離サブリポジトリ（プロジェクト）でも回避できます。 -- Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ja+owner@opensuse.org