AIDA Shinra
aida-****@jcom*****
2002年 10月 27日 (日) 15:22:47 JST
相田です。 3.6が出たので、開発体制や今後の方針をはっきり決めた方がいいと思います。 箇条書で検討すべき点を挙げます。 A. commitの仕方 私は勝手にcommitしていく形を推しましたが、分野ごとにcommit係を決めるス タイルも考えられます。あと、変更の詳細を明らかにするために、commit時に メールを出した方がいいかもしれません。(ChangeLogをまじめに書く方を優先 すべき?) B. 安定版、開発版を分けるべきか 曲がりなりにもserverなので分けるべきだと思います。ただ、安定版の位置づ けは、実験済の新機能は入れて行くのか、それともバグ等の修正に限るべきか、 微妙です。新機能を入れないと、誰も安定版を使ってくれなくなるので、私は 前者がいいと思いますが、Linux等では古いバージョンにパッチをバックポー トしたものが配布されることがあるので、それが嫌なら安定版は完全にfreeze とすることになるでしょう。 C. バージョンの付け方 3.6.1のような付け方が流行りですが、昔のように3.6p1のような付け方でもい いでしょう。p1のような付け方なら、バグフィックス版という印象になるので、 これはB.とも関係してくると思います。まあ、機能を追加したら有無をいわさ ず3.7にすればいい、という話もあります。あと、w3mのように、ChangeLogの リビジョンをpatchlevelに入れるのも面白いかも知れません。 D. .soのリビジョン問題 今度こそ1.1か何かに統一したいです。 E. canuum 最初はcanuumなんか消してしまえ、と思っていたのですが、需要がないわけで はなく、3.6の配布にもcanuumは一応入っているので、存続の方向に傾いてい ます。捨てるのが一番楽ですが、存続させるなら、 1. ちゃんとしたものを最初から作る 端末エミュレータを最初から作ることになり大変。これは避けたい。 2. canfepのような簡単なもので済ませる。 これなら楽。ただし、日本語を入れるたびに画面が乱れて、ctrl-uを頻繁に押 す羽目になる。ちなみに、canfepそのものは、システムコールやlibcannaの APIへの誤解がみられ、採用はできない。 3. GNU screenへのcannaパッチに移行する。 これが一番機能面では嬉しい。パッチを作ること自体は楽だが、本家との同期 をどう取るか、という問題がある。 4. Wnn4のcanuumにパッチを当てて使う。 手間は最も少ないが恰好悪い。 5. FreeWnnからcontribという形でuumを持ってくる。 FreeWnnが仕事をしてくれたので、移植性などの問題はかなり解消されている。 元のuumからそれなりに変更されている上、インデントを変えられているので、 どこが変わったか把握しにくい。 が考えられます。やりたくない方から順に並べています。なお、どの場合にも 共通するのですが、libcanna自体にバッファオーバーランがあるようなので (未検証)、セキュリティ問題はどうしても出て来ます。System V系のptyなら、 ptyの確保自体には特権が要らないので、utmpを諦めればセキュリティ問題は 無くなりますが、BSDでは、root権限無しではttyの覗き見を防げません。ただ、 特権を分離するのは難しくないので、3.以外の場合は心配は要らないでしょう。 3.の場合は、特権分離のような仕組みを入れるのはCanna Projectの仕事では ないという気がしますし、他のGNU screenの機能にも、root権限の要りそうな 部分があるので、対応は難しくなります。この問題が無ければ、3.がベストの 選択になると思うのですが。 F. CVSのブランチの切り方 安定版と開発版を分けるとして、どちらをブランチにすべきか、という問題が あります。CVSとして常識的なのは、安定版をブランチにする形ですが、開発 版のリリースを作る気が無く、安定版にも機能を入れるなら、開発版の方をブ ランチにすると作業が楽になりそうです。 G. リリースの出し方 「そろそろ出そう」と思った人がMLに提案して、異論が無ければタグを付ける、 という程度で大丈夫でしょう。ただ、最終的なモノを作る人は決めておくべき だと思います。リリースしたら直ちにWebに告知する等の作業が必要になり、 またリリースノートなども書かねばならないので、これはdoc/www担当がやる のが、一番タイムラグが小さくて済みそうです。 ---------- AIDA Shinra
