■
仕事始め。とりあえずDataSetのbugfix。
受け容れられやすいパッチの作り方
- なるべくatomicに。ひとつの問題につきひとつのパッチを作る
- パッチごとにChangeLogのエントリを作る
- 修正されたバグを古いコードで再現できるようなNUnitテストを作る
- 新しいバグを見つけてその修正コードを書いたら、まずbugzillaに登録して、バグ情報とパッチを同時に載せる
こんなところでしょうか。
Monoをhackするにはテキストエディタでやらなきゃいけない?
ライブラリによりますが、必ずしもそんなことはありません。僕は1年ばかりの間は、VS.NET 2003を使ってSystem.Xml.dllを開発していました。VS.NETにNUnitAddinを追加すれば、nunitテストも実行出来ます。ステップ実行もできるし、デバッグも出来るから、VS.NETの便利さにジャンキーになってしまってもう抜け出せないのだけど、mono hackingに参加してみたいという方にも、道が閉ざされているわけではありません。
むしろ、MSのライブラリとMonoのライブラリを混在させて動作させることによって、問題の切り分けが簡単になることだってあるのです。たとえばmscorlib.dllとSystem.dllはMS.NETのを、System.Xml.dllはMonoのを使う、といった方法によって、System.Xml.dllの問題を発見することができます。System.Data.dllを直すとき、あえてVS.NETを使ってMSのSystem.Xml.dllを参照して開発したこともあります。（VS.NETに戻るのもけっこう苦痛でしたが。）
そのかわり…
- コーディング規約が全然違うので、エディタ上での作業はけっこう苦痛になります。むしろVS 2005を使った方が効果的?
- VS.NETでコピペを行ってからファイルを保存すると、改行文字が壊れたり混在したりすることがあります。全部もとの改行コードに統一して保存し直す必要があります。まあ、これはdiffを作って読んだ時点で分かりますが。
- 手元で修正したコードが上手く動作するからといって、それがmonoで動作するとは限りません。途中に実装していない機能が使われていた場合、そのコードがコミットされることはないでしょう。（途中で使われているものも実装してもらえれば、もちろん問題ないのですが。）
- native dll invocationが含まれていると、monoでは動作しないことがありえます。
- mscorlib.dllやSystem.dllは、VS.NETで作業できるかどうかは分かりません。System.Xml.dllはほとんど問題なく作業出来ましたが、参照を変更するごとに挙動不審になっていました。