[ruby-dev:13258] Suggestions for Ruby development

　Ruby の開発について二つ提案があります。

1) ユーザから見た変更点のサマリーを記したファイルを ChangeLog
   とは別に用意し、メンテナンスするようにしてはどうか。

　今のところ、以下のようなサイトで変更点がまとめられていますが、
常に開発をウォッチして変更を記していくのは大変な作業です。

http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=ruby+1.6+feature
http://www.pragmaticprogrammer.com/ruby/new_features.html

そこで、 ChangeLog とは別に NEWS のようなファイルを用意して、
ユーザから見えるような比較的大きな変更は commit する際にその
ファイルに書き加えるようにしたらいいと思うのですが、いかが
でしょうか。

　NEWS はブランチごとに保守し、

    - 安定版では過去のリリースからの変更点を書いていく。

    - 開発版では最新の安定版からの変更点を保守する。安定版に
      バックポートする際には、該当項目を安定版の NEWS に移動

という風にすればよさそうです。

　NEWS の保守により、現在履歴管理に弱いのではないかと言われている
RWiki 等で履歴を保存する必要が必ずしもなくなるかもしれません。


2) 開発版から安定版へのバックポートの目安にするため、 commit log
   あるいは ChangeLog に何か分かりやすい目印を書くようにするのは
   どうか。

　つまり、開発版に変更を加える際、安定版にも同じ変更を加えたい、
というときにそれを何らかの印を付けるようにしましょう、という提案
です。具体的な説明のため、 FreeBSD での例を挙げます。


　FreeBSD には、 Merge From Current の略で MFC という用語があり
ます。Current というのは CVS の幹、つまり HEAD ブランチのことで、
つまり MFC とは「HEAD からのマージ」という意味です。同様に MFS は
「安定版(Stable)からのマージ」であり、一般的に MFhoge といえば
「hoge ブランチからのマージ」を意味します。

　どういう風に使うかというと、開発ブランチで加えられた変更を安定版
ブランチにバックポートして commit する際に、ログに

	MFC rev.1.23: Fix a bug in foo().

などと書くのです。もちろん、詳細なログは HEAD に commit したとき、
この例の場合だと rev.1.23 に書いてあるわけですが、これにより詳細な
ログを二度書かなくてもよくなります。同時に、開発ブランチの方で
すでにテストされた変更であることも明示できるわけです。

　一方、開発ブランチに commit する際も、安定版ブランチへの早期の
マージを意図している場合は

	MFC in: 3 days

などと書いておきます。これにより、あとで何をバックポートすべきか
忘れたときにも検索することができるわけです。

　同時に、これはそこに書かれた日数のテスト期間後に安定版にマージ
するという約束にもなりますので、バグレポートした人に「そろそろ
マージしていいはずだけど、忘れてるのかな」「遅いから改めて安定版に
ついてもレポートしようか」などとやきもきさせることがなくなります。

# ちなみに FreeBSD では、 MFC in: とか MFC after: といったログ
# メッセージを見つけると、自動処理スクリプトによってスケジュール
# され、指定した時間の経過後に担当の committer にリマインダーの
# メールが送られるようになっています。


　特に Ruby の開発について言うと、これはまつもとさんの負荷を減らす
のに効果的だと思います。つまり、些細な修正については、 HEAD の方に
commit する際、ログの中に「この変更は ruby_1_6 の方にも適用される」
という意味の印を書いて頂くことにするのです。

　そうすれば、もしある変更が ruby_1_6 の方にマージされていない場合、
その変更は HEAD にだけ適用される意図だったのか、それともテストが
終わっていないのか、あるいは単にバックポートを忘れているのか、
他の人が確認したりバックポートの可否を求める手間が省けます。

　まつもとさんがご自分ですべて覚えていて頂く必要もなくなりますし、
手の空いている他の committer がバックポートすることで、実際の作業の
負荷も分散できることでしょう。

　もちろん、少々入り組んだ変更や安定版リリースの直前の火急を要する
場合はご自身でやっていただくのがベストですが。


　導入する場合、決めておけば印はどんなものでもいいと思いますが、
例えばこのくらいでどうでしょうか。

	[->1.6]			1.6 にすぐにでもマージしてよい
	[->1.6: 1 week]		一週間は待つべし
	[->1.6: ?]		マージはいずれするが、時期は未定
	[1.7]			1.7 からのマージである

    例)
	* foo.c: fix a typo. [->1.6]
		すぐマージしたい

	* bar.c: add a new method: Bar#bleh(), which blehs.
	  [->1.6: 3 days]
		テスト・レビューのため三日くらいは置きたい

	* baz.c: obsolete a method: Baz#bleh().
		マージはしない

	* foo.c: fix a typo. [1.7]
		1.7 からマージされた

	* bar.c: new method: Bar#bleh(). [1.7]
		1.7 からマージされた (ので特に詳細は書かない。
		新しいメソッドなので、概要はおそらく NEWS の方に
		書かれている。詳細は CVSweb 等で分かる)

なお、 1.6 と 1.7 にほぼ同時に commit する場合は何も付けなくて
いいと思います。あくまで、備忘のため、共同作業の助けとするための
目印です。

-- 
                     /
                    /__  __            Akinori.org / MUSHA.org
                   / )  )  ) )  /     FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ /  ( (__(  @ iDaemons.org / and.or.jp

"Freeze this moment a little bit longer, make each impression
  a little bit stronger..  Experience slips away -- Time stand still"