著作: 問題になる修正案の作り方について†
- ページ: BugTrack2
- 投稿者: henoheno
- 優先順位: 普通
- 状態: 着手
- カテゴリー: その他
- 投稿日: 2010-09-05 (日) 21:59:48
- バージョン:
はじめに (お断り)†
以下の話題や事例は、PukiWiki Developers Team 側の一方的な主張ないし行動、あるいはこれまでの行動の背景事情にすぎませんが、互いの著作、およびプロジェクトの未来を不用意に失わないための形式を、ある程度広く示す目的で掲載するものです。
メッセージ: 手抜きが全ての始まり†
多くの場合において、よほどの偶然が無ければ、その結果は後に残りません。
- どのような手順であれば、最大限の効果を発揮するパッチになるのでしょうか。
- どのような手順であれば、最小限の労力で失敗する修正案になるのでしょうか。
修正案を検討する (その提案の将来性も含めて)†
- 調べ切れていないものは、調べる/考える (後からでも良い)
- 背景事情
- それが何であるか、何とどう違うのかについて
- あれば、プロジェクトの思想信条的なもの
- 将来どのようにあるべきか
- どこに、どのように提出するのが最も効果的か
- やっつけ仕事や、「作ってみた」と自称する類の物件のメンテナンスを委譲しようと試みない
- 偶然を除けば、プロジェクトの将来性とバッティングするかもしれない。
- 誰かがボールを返してくれるチャンスを除けば、誰かに再検討の負担をかけるかもしれない。
- 元の認識がずれている場合、相当な負担を周りに強いるかもしれない。
- パッチが取り込まれることを期待してはいけないかもしれない。
修正案(パッチ)をつくる†
リビジョン管理ツールで妥当なリビジョンを調達する†
- cvsが使われている場合はcvs で HEAD(最新の開発版) ないし、妥当なリビジョンを調達する
自分の知見を最小限盛り込む†
- 文字コード、改行記号、タブ記号、改ページ記号などを破壊するエディタを使ったら採用されないか、余計な手間が発生すると思うべき。
- 余計な事は書かない。
- 例えばグチを書いたら採用されないと思うべき。
- その他に余計な要素が混ざっていると、余計な手間がかかると思うべき。
変更点と意図が明確になるように、diffをつくる†
- cvs diff -u3 のような方法で、変更点がわかりやすいパッチを作る。なお、比較元のファイル名とリビジョン番号を明記する。(cvs diff であれば先頭の2行が自動的にその仕事をしてくれる)
--- spam.ini.php 4 Sep 2010 13:51:58 -0000 1.199
+++ spam.ini.php 5 Sep 2010 12:54:13 -0000
@@ -7089,76 +7089,103 @@
),
(以下略)
- diffは必ずツールを使って生成して下さい。さもないと、手作業によるミスの混入の可能性が生じます。
- diffを作る経過の中で、動作確認が必ず実施されているはずです。
- 例: 動作に手を入れるのが目的なのであれば、修正前と修正後のそれぞれの動作をチェックしながら作業せずにはいられないため。
- 例外: 本当にささいな修正、あるいはささいだと思っている修正、本当に余裕が無い場合など。
その他†
- 複数の話題であればパッチを複数作る。とても大事です。(コミットも複数回に分けるべき)
- 厳密には電子メールやsf.jpのパッチのシステムのような、改ざんしにくいメディアを選択する。(Wikiの特定コンテンツがそのように作られているなら、そこでも構いません)
- より厳密には著作権の委譲について、書面を提出すべきとなっていますが、PukiWikiはここまではやっておりません。
- PukiWikiはファイルヘッダに長いGPLの表明文を載せておりません(簡潔なものしかありません)し、編集者の一覧(テキストファイル)も現状ありません。
参考文献†
- (どのように書けば提案がreject されるのか、という記事がどこかにあったような気がするのですが)
コメント†
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
wkltg_50.png