[Tomoyo-dev 262] Re: TOMOYO Linux 1.4.2 / TOMOYO GUI 1.0.1 公開しました。

アーカイブの一覧に戻る

Toshiharu Harada harad****@gmail*****
2007年 7月 15日 (日) 09:18:12 JST


これはまた長く書きましたね。

07/07/15 に Tetsuo Handa<from-****@i-lov*****> さんは書きました:
>  熊猫です。
>
> > > > 上で言う「互換性」と「長期的なサポート」の内容がよく見えません。
> > > > どこまでの範囲をどのようにサポートしようとしていますか?
> >
> > 半田さんは、以下のリプライで長々と書いていますが、上で
> > 私が尋ねた内容には答えず、サポートに関する別の問いかけを
> > しています。これでは議論が発散します。まず、質問に
> > 答えてもらえませんか?
>  どこまでの範囲をどのようにサポートするかは私が決定できることではありません。
> NTTデータの手によって、あるいはコミュニティの手によって
> どこまでサポートしていくべきか目標を議論していく必要があります。
> まだ決定していない以上、「ディストリビュータによるサポートが終了するまで」とか
> 「24時間386日のサポートを行う」とかいった範囲について言及できないので
> わざと言及しなかったわけです。

質問への回答としては、例えば「1.4以降についてディストリビュータによる
サポートが終了するまで」ということを実現したい(すべき)と考えて
いるということですね。

「言及できない」についてはそうは思いません。個人としての考えや
意見を述べることは自由であり、特に問題、課題意識を持ち、他と
議論したいのならそれをまず明確に伝えるべきです。自分の意見を
表明せずに意見は集まりません。

「どこまでの範囲をどのようにサポートするかは私が決定できることでは
ありません」については、「NTTデータが」という前提が置かれていると
思いますが、サポートはNTTデータ(だけ)が行うと決まったわけでは
ないですし、半田さんはNTTデータがサポートを行うよう自ら動くことも
可能です。

> TOMOYO 1.1 での書き込み権限の細分化、 1.2 での if 節のサポート、
> 1.3 のドメイン単位の制御モードの切り替え、 1.4 でのポリシーエディタの使い勝手向上という
> 進化により、業務システムにも導入できる実用的な機能を備えたと考えています。
> Wiki に書いてくれた6名のユーザの中には、まだ TOMOYO 1.2 を使っているという方も居ました。
> 新しいバージョンがリリースされたら旧バージョン用のパッチの更新が放置されてしまう現状は
> 旧バージョンのユーザにセキュリティホールを放置させてしまうことになっており、
> 心苦しく思っています。
> 1.3 以前は無理だとしても、 1.4 以降は長期サポートしていきたいと思うのです。

サポートについては、できる範囲で考えるべきで、希望や理想をベースに
考えるべきではないと思います。できないものを請け負っても喜ぶ人は
いません。ひとつの方法としては、旧バージョンからの1.4への以降を
呼びかけ、その手順を示すということが考えられます。

> > 因果関係がよく理解できないのですが、半田さんは、TOMOYO本体のバグ修正や
> > 機能拡張にtomoyo-devのメンバーが専念できておらず、その原因が
> > NTTデータにあるということを言いたいのですか?
>  違います。

半田さんが書いたメッセージを素直に読むと、上のように見えて、
NTTデータに対しての不満(愚痴)を書いているように見えました。
半田さんの中に不満や問題意識があることは、強く伝わって
くるのですが、それを解消するには真の原因を明らかにすることが
大切だと思います。

> 1つは、サポート体制を約束する姿勢をNTTデータが示せていないがために
> 潜在的な案件をみすみす逃していることが勿体無いと言っているのです。

NTTデータとしての具体的サポートの内容や条件は、具体的な
相手が存在してはじめて議論できると思っています。
「1.4で良いので使いたい。そのためのサポートを受けたいので、
条件を教えて欲しい」、というようなユーザが現れたら今日からでも
具体的な話をすることができます。具体的なユーザがなく、
メインラインにはいっていない状態で、24時間365日のサポートを
行いますということは、NTTデータに限らず誰も約束できないでしょう。
また、他のメールでも書きましたがNTTデータ以外サポートしては
いけないという決まりはありません。
最後に、サポートについては、半田さん個人としてできることも
あるはずです。それを考えてみることもして欲しいと思います。

> もう1つは、案件とは無関係な話です。
> TOMOYO 本体のバグ修正や機能拡張に専念できるようになるためには
> ディストリビュータカーネルのアップデートに追随するための稼動を減らしたいが、
> そのためのノウハウがまだ TOMOYO ユーザに浸透していないと言っているのです。

そのような問題意識や不満があるのはよくわかりますが、それを
解決するのはユーザと語り合うことが一番だと思います。
7月12日のYLUGで半田さんは懇親会に参加せず帰ってしまいましたが、
もったいないと思います。別に「ユーザ会」や名称にこだわらず、
mlのメンバーに呼びかけ集まりを開けば良くて、誰もそれを
禁止しないし、会社の手続きも不要です。

> > 行って欲しいのです。また、Subversionを協同開発に使っていないのは、
> > 半田さんなりの理由があると思うのですが、それを説明して
> > 欲しいとも思っています。
>  ポリシーエディタの色付けのように TOMOYO カーネルの仕様を知らなくても
> 開発に参加できる部分はありますが、限られてしまいます。

半田さんが「限られている(できない)」と思った瞬間に開発への参加は
絶たれてしまいます。できる人はいるかもしれないし、少なくとも
dev-mlの人たちはそれをしたいと言って集まってきてくれたのです。
trunkで最新のソースを共有し、参照、議論できる環境を
作らない理由は思い当たりませんし、私の意見としてはそれが
協同開発の最短の道です。

> 開発やテストに参加できない原因の大部分は私にあります。
> TOMOYO の仕様を理解してからでないと開発の議論やテストに参加できないのに、
> 私から皆さんへのノウハウの受け渡しがうまく進んでいないのです。
> どんどん仕様や使い方についての質問をして欲しいのに、何故か1つも質問が来ません。
> 全仕様を理解しているのなら良いのですが、質問が来ないのは
> 「どんな機能がありどのように使うのか判らない」とか
> 「どこから質問したら良いか判らないほど使い方が判っていない」とかいう
> 状況になっているからではないかと心配しています。実際、不満や質問があっても
> mlには投げずに、先日の YLUG の時のように口頭で質問やアドバイスをしてくれる
> 協力者が多いと思っています。

理由をあれこそ想像して悩むより、会って話をすべきです。
名称は何でも良く、実際にtomoyo-devの人たちに会って、何がネックか、
何を希望しているかを聞くことから始めませんか?それは
私がいなくてもできることですし、会社としても何の問題もありません。
(当たり前ですが一応書いておきます)

> ドキュメントに不足している内容を Wiki に書き足したりしたいので、
> ノウハウを受け渡すためにどんどん質問して欲しいのです。
> mlに質問内容が残るのが嫌なら個人宛でも構いません。
> 匿名で質問したければ Wiki や熊猫さくらのブログ宛でも構いません。
>
> Software Design の連載で TOMOYO の使い方について書いていますが、
> ページ数の制約から全機能を紹介することはできていませんし、
> ある機能が実装されてから連載という形で共同開発者の手元に届くには
> 2ヶ月掛かってしまい、その頃には次の機能が実装されてしまいます。
> この方法ではいつまで経っても TOMOYO のノウハウを受け渡ししきれません。

という不満があることがわかりましたが、これは並行してWikiに
原稿を書いて掲載すれば良いのではないでしょうか?

> 私だけでは TOMOYO Linux のユーザが読んで満足する内容の原稿を書けません。
> しかし、出版前の原稿を誰でもレビューできる状態にしてしまうと
> 出版された本を誰も買わなくなってしまうのでできません。

ということであれば、私のほうで技術評論社に相談して連載を
やめても良いです。

> そのため、社内のメンバーにしか原稿レビューをお願いできないでいます。

これはおかしい。レビューを依頼したければ、dev-mlの方々に
読んでもらうことは可能です。

> ただ、何年も原田さんと仕事してきた経験から
> (何日も前に私が原稿案を書けたとしても)設定された締切日の直前まで
> 原稿レビューに取り掛かれないほど原田さんは業務が多忙であり、
> 具体的な締切日が設定されていないと何ヶ月でも遅れてしまうのが見えています。
> 締切日が設定されていることで何とか連載が続いているという状況です。
> 締切日が無くなったら全くレビューをできなくなるのではと心配です。
>
> いっそのこと、 Software Design の連載の原稿レビューをするために非公開の Wiki を作り、
> Wiki で Software Design の原稿レビューをしていくようにしますか?
> それだったら原田さんに原稿チェックのための稼動を掛けさせないで済みます。
> 執筆者は個人ではなく TOMOYO Linux 開発チームということで。

つまるところ、私のレビュー稼働がネックになっているという認識
なのでしょうか?問題の所在を明確にしたいです。もし、私のレビューが
ネックなら、私が執筆者からはずれて半田さんが単独で書いても
良いのです。

> TOMOYO プロジェクトで不足しているのは
> (1) カーネルの構造やシステムコールの使い方についての知識を持つ人
> (2) TOMOYO カーネルとツールのテストケースを作成できる人
> です。しかし、 (1) については日本国内には多くはいません。
> (2) については TOMOYO の仕様を理解すれば実際にポリシーを定義してみて
> 期待した通りに動作しているかどうかをテストすることができます。
> テスターとして参加していただいているのは嬉しいのですが、
> テストケースを作成できるだけの TOMOYO の仕様について理解を共有できていないため、
> 私だけがテストケースを作っており、仕事を振ることができないでいます。
> (テストケースを考えるのは数時間〜数週間、テストをするのは10秒です。)
>
> 決して tomoyo-dev の方たちを責めているわけではありません。
> 責任の大部分は私がノウハウを皆様に伝承できていないことにあるのです。

半田さんにそのつもりがなかったとしても半田さんのメールからは、
自分以外への不満やうらみのようなものが伝わってきます。
また、真の原因や問題意識が見えませんから、改善を手伝って
あげたくてもアクションがとれません。もし、「責任の大部分は私が」の
部分が本心なら、その不満は自分に向けて、他の人ができることを
一人称で進めていくべきです。僕はそれを最大限に支援しますし、
tomoyo-users, tomoyo-devのメンバーも手伝ってくれるでしょう。

-- 
Toshiharu Harada
harad****@gmail*****




tomoyo-dev メーリングリストの案内
アーカイブの一覧に戻る