Kensuke Nezu
nez****@samba*****
2007年 7月 20日 (金) 15:28:37 JST
根津です。 On 2007年 7月 20日 (金) 13:21, Toshiharu Harada wrote: > 自分で補足します。 > > 07/07/20 に Toshiharu Harada<harad****@gmail*****> さんは書きました: >> 07/07/15 に Tetsuo Handa<from-****@i-lov*****> さんは書きました: >> > Software Design の連載で TOMOYO の使い方について書いていますが、 >> > ページ数の制約から全機能を紹介することはできていませんし、 > > 各回のページ数は5~9ページが目安ですが、過去最大10ページでした。 > 「連載」なのでページ数は分割単位（区切り）であり、絶対的な > 制約ではないですよね。 > >> > ある機能が実装されてから連載という形で共同開発者の手元に届くには >> > ２ヶ月掛かってしまい、その頃には次の機能が実装されてしまいます。 >> > この方法ではいつまで経っても TOMOYO のノウハウを受け渡ししきれません。 > > ここは私は不思議な気がするところなんです。 > > 新規の機能を実装しているのは半田さんなわけであって、 > 早すぎるのならもっとゆっくりしたら良い気がするのですが > それでは駄目ですか？（笑）自分で自分に追いつけないと > 言っているような気がします。 それよりも、アップストリームマージを目指しているステージでは、新機能の 追加や大きな変更はせずに、コードの安定性やバグだしなどの品質向上を目指す べきなんじゃないかと思うのですが・・・。 基本的にstableなものでないと、アップストリームにマージするのは難しいと 思いますので、ある程度のところでFIXし、その技術のTTと品質向上に注力すべき ではないでしょうか？ > 書籍の遅延を気にするのであれば、実装と同時に > 新機能の紹介をWikiに掲載というのはありだと思います。 > ただ、全体として、読者は必ずしも最新、最先端の > 機能に追随しているわけではなく、全てのユーザが > それを希望しているとも思いません。（という意見です） 新機能をどんどん追加しながら、それをことごとく教えることがThinkITの記事の 使命とは私には思えません。それは、READMEなりソースなりをwatchすればいい のであって、ThinkITの記事は、観光ガイドみたいなレベルでいいのだと思います。 >> > いっそのこと、 Software Design の連載の原稿レビューをするために非公開の Wiki を作り、 >> > Wiki で Software Design の原稿レビューをしていくようにしますか？ >> > それだったら原田さんに原稿チェックのための稼動を掛けさせないで済みます。 >> > 執筆者は個人ではなく TOMOYO Linux 開発チームということで。 > > 私の場合ですが、執筆者は書かれた内容に責任を持つ人で、最終的には > （複数人からレビューを受けたとしても）個人というのが > 考え方をしています。（それを押しつけるつもりはありませんけれど） > 自分が書いたり確認した資料以外には名前はつけないように > しています。チームとか研究会名義のものもあっても > 良いとは思います。 チームで仕事を請けて、（TOMOYOユーザ会とか？）割り当ては内部で決めるのは ありでしょうが、署名のない記事は責任がないので困ります。 ＃出版社的にも原稿料を払う「誰か」が必要ですしｗ -- ------ 根津 研介 日本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