• Home
• コーポレートブログ
• Redmineのパッチを書くときに気をつけていること

今週のブログ担当、石川です。
先日はRedmine.tokyo 第13回勉強会に参加し、参加者の皆さんの「Redmine愛」にたくさん刺激を受けました。私もRedmine愛を発信せねば！ということで、今回のブログは Redmine Advent Calendar 2017にエントリーしています。Advent Calenderに参加するのは初めてなのでドキドキです。

Redmineはオープンソースソフトウェア

Redmineはオープンソースソフトウェアです。コードは公開されており( redmine - Revision 17120: / )、公式のRedmine上( Overview - Redmine)で誰もが開発に関わることができます。

貢献の形は様々(機能要求・バグ報告チケット作成、ドキュメント拡充、コード修正…)ですが、今回はそのうちのコード修正について書こうと思います。

↓Redmine貢献については以下で詳しく書かれています

Redmineの開発は公式のRedmine上で行われており、コード修正は、コードのdiffをパッチ化してチケットに添付することで行われています。

普段パッチを書くときに気をつけていること・意識していること

今回は、普段私がパッチを書く際に気をつけていること・意識していることを書きます。(Redmineに限らないことは沢山あります) あくまでも私が気をつけているというだけなので、これが正解というわけではありません。

最新のtrunkに対してパッチを作成する

パッチを作る場合、その時点での最新のtrunkにコンフリクトなく適用できるようにすべきだと考えています。(3.4-stableなどでなく)

パッチをRedmineに投稿するとそのパッチを実際に適用してレビューしてもらえることがあるのですが、適用の際に大量にコンフリクトが起きることでその機会を失ってしまう可能性があります。(誰だってわざわざ大量のコンフリクトを直してまでレビューしようとは思いません)　また、あまりにもコンフリクトが多いパッチは誰かが最新版に合わせる努力をしないとコミットされません。

最新のtrunkに対して適用できるようにすることで、頑張って書いたコードがより取り込まれやすくなるということです。パッチを作ったときのtrunkのリビジョン番号を記載しておくとさらに良いと思います。(私もあまりできていませんが)

バグ報告時にはできるだけ多く情報を出す

せっかくバグ報告をしてもらっても、情報が足りないが故にバグを再現できず、そのまま放置されてしまうこともあります。できる限りたくさんの情報を載せて、バグが再現できるように気をつけています。

実際にチケットを作る時は http://www.redmine.org/projects/redmine/wiki/Submissions を確認すると良いと思います。

関わったチケットはウォッチしておく

Redmineの場合はチケットにパッチファイルを添付するという形でアクションをするので、履歴を見てもただコメントをしたのかパッチを投稿したのか、ぱっと見ではわかりません。今後もそのチケットの様子を見るためにチケットをウォッチしておくと良いと思います。

また、Redmineでの貢献活動は正直あまり目に見えないのですが、関わったチケットをウォッチしておくとMy Pageなどで後から確認して幸せな気持ちになれます。

プラグインの存在を意識する

ここは普段私もできているか怪しいところなのですが、大切なことだと思っています。

Redmineには現在様々なプラグインが作られており、何気なくメソッド名や定数名・引数を変えるだけでもいくつかのプラグインを壊してしまう可能性があります。勿論変えざるを得ないことはありますが、しなくて済む変更ならばできるだけしないで済むように気を使っています。

たまにそれを忘れて安易にメソッドを変えたりして、こうしてRedmine公式でご指摘いただいたりします。

テストはできるだけ書く

テスト無しの場合は誰かがテストを書いてくれるまでマージされません。注目されるような大きな変更の場合は書いてもらえることもありますが、そのまま放置されてしまう場合もあります。

苦手でも他のテストを参考にとりあえず書いてみることが大事だと思います。

分割できそうなパッチはgit format-patchでつくる

(gitの場合に限られます)
Redmineの公式リポジトリはSubversionなのですが、コミュニティにより管理されたGitリポジトリがGitHub上にあるので、それをcloneして開発を行っています。

普段は git diff > diff.patch という形でパッチを作成していますが、一つのチケットに対するパッチでも機能が多かったりする場合は、 git format-patch というコマンドを利用してパッチを作成しています。一つのコミットごとに一つのパッチを作ってくれるため作る側としても便利で、なおかつ適用する際にも git am コマンドで直接コミットを作成できるという利点があります。

完璧な英語にこだわりすぎない

Redmineのコミュニティは当然ながら日本人だけではないので、英語でコミュニケーションを取る必要があります。私は英語苦手人間なので、基本Google翻訳を利用して日→英翻訳に少しの手直しを加えて英語を書いています。

最初はgoogle翻訳を利用しても不安が大きく一文書くだけなのにとても時間がかかっていましたが、最近は完璧な英語でなく多少間違えていても察してもらえると信じてあまり時間をかけずに文章を書くようになりました。

「英語」というところで引っかかってコメントできない・チケットを作れない人もいると思うのですが、そういう時はスクリーンショットを駆使すればなんとなく伝わると思うので、勇気を出してみてください。

コメントでパッチのアピールをする

このパッチが適用されることでXXXXなところが便利になります、喜ぶ人はたくさんいます、などとアピールする言葉をできるだけパッチ投稿の際に添えるように気をつけています。必要性をわかってもらうことはパッチを取り込んでもらうための第一歩だと考えています。

Redmineへのコード面での貢献活動をしてみて

Redmineへの改善パッチを書く中で、愛着が湧き、Redmineをどんどん好きになっていっています。今後もRedmineのパッチを書く活動を続けていきたいです。