T.SHIOZAKI
tshio****@astec*****
2002年 10月 28日 (月) 14:46:57 JST
塩崎です。 あくまでも個人的意見なので参考程度ですが、 From: AIDA Shinra <aida-****@jcom*****> Subject: [Canna-dev 53] new canna development again Date: Sun, 27 Oct 2002 15:22:47 +0900 Message-ID: <86of9****@jcom*****> > 3.6が出たので、開発体制や今後の方針をはっきり決めた方がいいと思います。 > 箇条書で検討すべき点を挙げます。 > > A. commitの仕方 > 私は勝手にcommitしていく形を推しましたが、分野ごとにcommit係を決めるス > タイルも考えられます。あと、変更の詳細を明らかにするために、commit時に > メールを出した方がいいかもしれません。(ChangeLogをまじめに書く方を優先 > すべき?) Canna ぐらいの規模で commit 係を決めても繁雑になるだけだと思います。 せっかく cvs を使っているので、 - 大きな変更は聞いてから commit する。 - たいした変更ではない(と、ある committer が判断した)場合には、 勝手に commit 。 - 問題があったら協議により戻す。 というのがきっと楽です。 メールに関しては、(大きな変更時に)コンセンサスを取るための commit 前のメールと、あまりに込み入った変更の場合に(慣れた日本語で) 説明するための commit 後のメールは必要な場合もありますが、 commit 時のメールは、せっかく cvs メーリングリストがあるのだから、 commit mail をちゃんと書く、で十分でしょう。 > B. 安定版、開発版を分けるべきか > 曲がりなりにもserverなので分けるべきだと思います。ただ、安定版の位置づ > けは、実験済の新機能は入れて行くのか、それともバグ等の修正に限るべきか、 > 微妙です。新機能を入れないと、誰も安定版を使ってくれなくなるので、私は > 前者がいいと思いますが、Linux等では古いバージョンにパッチをバックポー > トしたものが配布されることがあるので、それが嫌なら安定版は完全にfreeze > とすることになるでしょう。 これは難しくて、F. とも絡むのですが、 - 大きな変更をするのならば、ブランチは必要 - 開発版はやっぱり trunk にいたほうがいろいろと便利 - とはいえ、ブランチに pull up するのはちょっと面倒 というトレードオフなので、 - ひんぱんにリリースするならば基本的にブランチを切らないで、 開発が必要なときは「実験ブランチ」を切る。 - もし今後、大きな変更をしつづける予定があるのならば、 とりあえず trunk から一度安定したリリースを出してから、 安定版をブランチ。trunk は開発に使う。 という二つのやり方があるでしょう。 ブランチをどの程度の頻度で切るか、というのもお里によって違って、 BSD 方面だと「最低限しか切らない FreeBSD」と、 「個人が実験用にバンバン切っていい NetBSD」という違いがあります。 この辺は完全に好みですね。 まあ、どれをお使いになっても、似たようなもんですが。 > C. バージョンの付け方 > 3.6.1のような付け方が流行りですが、昔のように3.6p1のような付け方でもい > いでしょう。p1のような付け方なら、バグフィックス版という印象になるので、 > これはB.とも関係してくると思います。まあ、機能を追加したら有無をいわさ > ず3.7にすればいい、という話もあります。あと、w3mのように、ChangeLogの > リビジョンをpatchlevelに入れるのも面白いかも知れません。 patch release が大量になされる可能性があるのならば、 patch version を 0 ではなく 00 とか 000 とかから始めるべきで、 そうなると、3.6.01 はいかにも不格好なので、 3.6p01 とかかな、という気がします。 # 同様に 3.9 の次をどうするか問題などが発生しますが。 # 過去の事例では、GNU 流は 3.90 、OpenBSD 流は 4.0 。 # もちろん、patch release でも似たような解決方法は # 考えられますが、パッチの番号が 9 から 90 に # 飛んだりするのもわかりにくくてアレでしょう。 > D. .soのリビジョン問題 > 今度こそ1.1か何かに統一したいです。 今の major が 1 ですから、1.1 にするのならば、 今後ずっと現在の ABI に対する後方バイナリ互換を 保証するということになると思います。 あまり Canna の API を見ていないので私には判断できない、 という意味で純粋に質問なのですが、今の ABI を残したまま 続けていけるという算段はありますか? # 経験上、マクロを駆使すれば、たいていの場合は ABI を保ちつつ # なんとかできるものですが。 あと、Canna との通信プロトコルの互換性についても、 ここで一緒に考えておくべきなのかな、と思います。 > E. canuum > 最初はcanuumなんか消してしまえ、と思っていたのですが、需要がないわけで > はなく、3.6の配布にもcanuumは一応入っているので、存続の方向に傾いてい > ます。捨てるのが一番楽ですが、存続させるなら、 ... > 3. GNU screenへのcannaパッチに移行する。 > これが一番機能面では嬉しい。パッチを作ること自体は楽だが、本家との同期 > をどう取るか、という問題がある。 > > 4. Wnn4のcanuumにパッチを当てて使う。 > 手間は最も少ないが恰好悪い。 > > 5. FreeWnnからcontribという形でuumを持ってくる。 > FreeWnnが仕事をしてくれたので、移植性などの問題はかなり解消されている。 > 元のuumからそれなりに変更されている上、インデントを変えられているので、 > どこが変わったか把握しにくい。 うーん、3 の screen パッチがあれば要らんような…… canuum 残すのならば、たぶん 4 か 5 だと思うんですが、 純粋に技術的な理由から 5 が簡単かなと思います。 > G. リリースの出し方 > 「そろそろ出そう」と思った人がMLに提案して、異論が無ければタグを付ける、 > という程度で大丈夫でしょう。ただ、最終的なモノを作る人は決めておくべき > だと思います。リリースしたら直ちにWebに告知する等の作業が必要になり、 > またリリースノートなども書かねばならないので、これはdoc/www担当がやる > のが、一番タイムラグが小さくて済みそうです。 そんな感じでしょうね。 P.S. そういえば、もともとの RCS ID が上書きされちゃってますけど、 これはそういうポリシにしたという理解で正しいですか? では。 -- Takuya SHIOZAKI / ASTEC Products, Inc.
