Kensuke Nezu
nez****@samba*****
2007年 7月 23日 (月) 11:27:09 JST
根津です。 ＃会議に参加できない人の意見も集約する意味で、MLでコメントします。 On 2007年 7月 23日 (月) 10:36, Kentaro Takeda wrote: >> ・今後の機能拡張の方向について >> ・ノキアからの要望への対応 >> ・独自機能 >> ・ 1.4.x では使えるが現状のＬＳＭ仕様では使えない機能の扱い > 今後1.xと2.xをどのように開発していくのか、どちらに軸足を置くのかが、 > 今後の方向として一番議論すべきことだと思います。選択肢としては、 > ・現状どおり2系統の開発を続ける 原田さんのコメントではないですが、開発要員の規模を考えると、これは テスト工数を無駄に食うだけですね。 > ・1.x系をテストベッドとし、2.x系に取り込む（FedoraとRHELのように） これもテスト工数が（プロダクションリリース的には）２倍になりますね。 > ・1.x系はフリーズして完全に2.x系に注力する > くらいでしょうか。 やはりこれしかないと思うのですが・・・。 > 07/07/22 に Tetsuo Handa<from-****@i-lov*****> さんは書きまし > た: >> ・メインラインへのマージを目指す活動について >> ・ SELinux または AppArmor と協力するのかどうか これは、TOMOYOのセキュリティモデルの抽象化を行わないと 少なくともSELINUXとは論議を戦わすことは難しいかもしれません。 >> ・保守体制について >> ・バージョン体系の変更（ 1.4.x の間は仕様変更を行わない） >> ・ディストリビュータ用カーネルのパッチ作成はコミュニティで行いたい >> ・導入支援と障害解析は企業としてサポートしたい メインラインに取り込むまでは、誰も一切、保障、支援がない状態と 考えるべきでは？ 少なくともパッチ作成をコミュニティで行う時点で、「サポート」は できない（だって保障できないですからね）と思うのですが・・・。 >> ・バイナリパッケージ配布で使う yum/apt レポジトリの運用について >> ・ディスクスペースの確保（ＬＳＭ化してもバイナリパッケージの用意が必要） >> ・ドメインの取得 ここまでは、コミュニティベースでやった方がいいと思うので、よければ 私がドメイン取ります。リポジトリについては、マスターサイトだけ用意 しておいて、あとは、RING Server Projectその他にミラーしてもらって 負荷分散できればいいと思います。 >> ・パッケージ名の変更 既存のパッケージとConflictしないパッケージ名にすべきですね。 >> ・デジタル署名の付与 リポジトリで配布するなら、GPGで署名するべきです。 >> ・ＮＴＴデータとして承認したバージョン／承認していないバージョンという区別をするのかどうか 保障がない上に、コミュニティでバイナリ作成しますし、そもそもオープンソース でforkだって自由なんですから、「NTTデータの承認」は何の関係もありません。 ＃NTTデータ社内では、きっと「承認されていないリリース」はありえないみたい ＃ですから、NTTデータ社内からのリリースは「承認されたバージョン」しかない ＃んでしょうが・・・。 -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/
TOMOYO
Fork