ヤマケンです。 uimのコミットポリシーについては過去に以下のような議論がありました が(wikiまとめありがとうございます)、これが足枷になって開発が滞っ てしまっては本末転倒なので、場合によってはもっと大らかなルールで 運用できるようにしたいと思います。ご意見お聞かせください。
http://anthy.sourceforge.jp/cgi-bin/hikija/hiki.cgi?CommitPolicy 現在の基本的なルールではコード変更を以下の4つに分類し、関連する変 更だけをまとめた上で個別に小粒度コミットする事になっており、また、 最低でもどの関数を触ったかを記録する事になっています。実例として は私のここしばらくのuim-sh関連の変更が参考になると思います。 ・拡張 ・修正 ・整理 (refactoring) ・整形 (cosmetic change) しかし、試行錯誤を伴うような見通しの立てにくい開発では上記の変更 が同時に複数必要になり、分離してコミットするのが難しい場合がある と思います。また、試行錯誤の度にフルにログを書いてコミットするの が億劫になるため、手元で開発を終えて清書済の完成版コードのみを uimリポジトリに入れる大粒度コミットスタイルの開発に流されがちにな り、個々の変更がいつ行われ、どの変更とどの変更が関連していたのか という情報が失われてしまいます。 そこで、libuimやscm/以下の基本ライブラリ以外のコードについては以 下のようなルールを適用しようと思いますがどうでしょう。 ・試行錯誤中の変更については上記の4分類及び詳細なコミットログは 不要とする ・変更内容を記録する事よりも、関連している小変更群をひとまとめ にする事と、日付を残す事を重視してこまめにコミットする ・ガンガンrevertする事を前提に、試験的なコードもとりあえずコミッ トしてから考えたり品質を上げたりする。手元に溜めない ・上記のようなスタイルの開発は、なるべくブランチを切って行う。 開発ブランチとして恒常的に切っておいてそこからtrunkにマージす るスタイルでもよいし、ちょっとした小目標のために専用ブランチ を切ってもよい ・試行錯誤が落ち着いたら、最終的な変更点をコミットログに残す (trunkへのマージ時等に一括でOK) こんな感じで今からでもuim-el-devブランチを切ってみるというのはど うでしょうか。 >渡辺さん なお、「libuimやscm/以下の基本ライブラリ」については、コミットロ グに加えてdoc/COMPATIBILITYというファイルで仕様変更を追跡している 事からも分かるように、詳細な記録が不可欠と考えています。 ------------------------------------------------ YAMAMOTO Kengo / YamaKen [メールアドレス保護] FAMILY Given / Nick http://en.wikipedia.org/wiki/Japanese_name --~--~---------~--~----~------------~-------~--~----~ Google Groups "uim-ja" group uim-ja@googlegroups.com http://groups.google.com/group/uim-ja/about -~----------~----~----~----~------~----~------~--~---
