TOKUNAGA Hiroyuki
tkng****@xem*****
2005年 9月 15日 (木) 07:40:43 JST
徳永です。 お待たせしました。コミットポリシー原案です。あまりまとまってませんが、こ れを叩き台としてコミットポリシーを確定したいと思います。あくまでコミット ポリシーですので、コーディングスタイルなどに関しては触れていません。スタ イルもぼちぼちと統一していきたいところですが、これはまた後ほど。（私は コーディングスタイルには大して意見は無いので、誰かが発案してくれると嬉し いです。） 一端コミットポリシーが策定された後は、全てのコミッタにポリシーを守ってい ただきます。ポリシーを破ったコミッタはペナルティとしてキムチシェーキを… とか考えたんですが、もう売ってないのであきらめます。 □コミットする単位に関して コミットするのは一まとまりの単位毎にしましょう。何をもって一まとまりとす るか、というのは難しい問題ですが、現状では、複数の機能改善等が一度にコ ミットされるケースが散見されます。これは以下の点で問題です。 ・revertしにくい ・コードを読んで把握しにくい コミット単位が小さくすると今度は動かないrevisionが出てくるよ問題が発生す るものと思われますが、とりあえずは現状を改善するために、コミット単位は小 さくしていきましょう。合言葉は「迷ったらこまめにコミット」で。 特に、バグフィックスと機能追加はできるだけ混ぜないようにしましょう。同じ 箇所に対する変更であっても、一端バグを修正して、それから機能を追加するよ うにしましょう。これは、バグ修正を安定版ブランチへ適用する事が目的です。 （ただし、「書き換えたらバグがなくなってしまった」というような場合は除き ます。このような場合は、深刻なバグであれば、別途0.4ブランチで修正するし かないでしょう。） □コミットの種類に関して コミットによりリポジトリに加えられる変更には、さまざまなものがあります が、ここではおおざっぱに以下のようにわけてみます。 (a)バグ修正 (b)機能改善（小） (c)機能改善（大） バグ修正は字面の通り、バグ修正です。機能追加（小）は、小さいコードの変更 量で新しい機能を追加したり、既存の機能を改善したりするものです。目安とし てはdiffが30行以内、ぐらいを想定しています。このような分類を作った目的 は、「この変更はどのブランチにコミットするべきか？」というのを簡便に判定 することです。 trunk:通常は制限なし。リリース三日前ぐらいからはcは行わない。0.6が近付 いたら状況は変わるかも。 0.4: a, bのみ。bを行うかどうかは各コミッタで判断。bの判断規準は「迷った らコミットするな。」逆に、trunkにコミットしたバグ修正は、問題なく適用で きる限り0.4にもコミットすること。 r5rs:制限なし。trunkへのマージが近付いたらしばらくはバグ修正とtrunkから の同期作業のみ。マージ時期に関しては別途告知を出すこと。 □trunkとr5rsの同期に関して r5rsブランチでsvk pullを行うと、自動でtrunkでの変更をr5rsブランチに追 加してくれます。というわけで、基本的には手作業でr5rsブランチにtrunkでの コミットを適用する必要はありません。1週間に1度、もしくはそれ以上の頻度を 目安にマージを行うこと。 □ファイルの追加に関して ファイルを追加した場合、Makefile.amに適切な記述を追加することを忘れる と、ビルドできなかったり、動かない原因になります。単純な場合に関しては make releasetestによるテストで回避できますが、以下の場合に関しては特に気 を付けて回避しなければなりません。 ・Schemeのファイルを追加した場合 ・デフォルトでconfigureオプションがオフの場合 前者はSchemeのテストコードを追加する事で回避できるでしょう。 後者はmake releasetestのルールを変更しないと回避できません。configure オプションを追加した場合は、make releasetestをいじる必要がないかどうか、 確認しましょう。 □テストに関して テストに関してはいろいろ改善したいところがあるのですが、とりあえず将来 的には「コミット前に関連テストにパスすることを確認すること」というポリ シーを入れたい、というのが希望です。 □コミット前の作業に関して svn diffで、コミット前に変更点をもう一度確認しましょう。 □コミットログに関して コミットログにはそのコミットの目的を書きましょう。目的が書けないような コミットは行うべきではありません。もしくは、目的の分類が不十分です。目的 は以下のようなものに分類されます。（ここに無いものがあれば追加してくださ い。） cosmetic change, bug fix, new feature, refactoring コメントやドキュメントの変更はどうしようか迷い中。以下のような感じで書 くことを想定しています。ログの書式は以下のような感じで考えてます。 [bug fix] Fixed a typo. * uim/uim.c: -(uim_init): Replaced 'uiim' with 'uim'. -- 徳永拓之 tkng at xem jp
