Redmineに関する課題と展望

RxtStudyやshinagawa.redmineで見聞したことを思い出しながらメモ書き。
間違っていたら後で直す。

【1】プライベートチケットの使い方

プライベートチケットはVer1.2から追加された新機能。
プライベートチケットに設定すると、初期設定されたロール以外の人からチケットが見えなくなる。

Redmine 1.2.0 released！: プログラマの思索

Redmineの大規模化の壁: プログラマの思索

プライベートチケットの使い道が最初は分かっていなかったが、@g_maedaさんから、Redmine本体の運用から生まれた機能であると聞いた。
例えば、redmine.orgへRedmine自体のセキュリティに関するバグチケットが登録された場合、そのチケットの情報が公開されることでRedmine本体に悪影響を与える可能性があるため、サイト管理者がプライベートチケットで隠してしまい、開発チーム内部でパッチを当てているらしい、と聞いた。
そのような使い方ならば、プライベートチケットの有用性はよく分かる。

プライベートチケットの今後の使い方としては、単なるソフトウェア開発のタスク管理だけでなく、会社全体のタスク管理へ拡張した場合、登録されたチケットの内容を社員全員に公開したくない場合があるだろう。
例えば、情報セキュリティや会計情報に関するチケットは、あまり公にしたくないものだ。
つまり、サイト管理者がプライベートチケットにして一部の人以外は非公開にして、管理者がプライベートチケットを非公開で対応するという運用方法もありうる。

【2】Gitリポジトリの並び順

RedmineのSCMリポジトリ画面では、Gitのコミットログの順序が正しくない症状は以前から知られていた。
第1回shinagawa.redmineでコミッタの丸山さんは、随分前のパッチによって、rebase前のコミットログの更新日が反映されたため、と仰っていた。
下記チケットで色々対応されている。

Redmine - Defect #5357: Git: SCM revisions ordered by date/time (should be reverse commit order) - Redmine

また、下記チケットにあるように、Redmineデータベースの最新コミット日から7日前以上のコミットログが表示されないような仕様もあったらしい。

Redmine - Defect #7146: Git adapter lost commits before 7 days from database latest changeset - Redmine

これは妥協の産物だったらしい。下記のTwitterにもその理由が一部書かれている。

Twitter / @wankomagic: Gitのブランチはリビジョンへのポインタだから、リビジョン間に何があったか表示するのが大変（しかも遅い）。Gitの特徴のせいかな？ #47redmine

Twitter / @munet9: Mercurialはリビジョン番号がある、リビジョン並び順が保証されているという２点でGitより断然有利、取り込みもとても楽、だとか。 #47redmine

Twitter / @naitoh: Git 7日間問題は、JPLの妥協案だったのね。 #47redmine

ITSがSCMリポジトリ参照機能を含むのは、No Ticket, No Commitの運用ルールが生まれた経緯もあって、とても重要な機能なのだが、SCMの種類によってはまだまだ問題があるようだ。
だが、丸山さんがコミッタになられてから、SCM関連機能がどんどん改善されているので、今後にとても期待しています。

【3】Ruby1.9とRails3対応

Redmineは2007年頃から開発が始まっていたために、下記チケットで随分前から改善要望はあがっているものの、Ruby1.9やRails3はまだサポートしていない。
Twitterを見ると、Ruby1.9やRails3をサポートして欲しいと思っているユーザは多いみたい。

Redmine - Feature #4050: Ruby 1.9 support - Redmine
Redmine - Feature #4796: Rails 3 support - Redmine

Redmine本家のリポジトリを見る限りでは、丸山さんが上記チケットに対応するように精力的に改善されている。
近い将来、対応されるだろうと楽観しています。

【4】Redmineコミッタへのパッチの送り方

Redmineへの貢献方法は下記HPに手順が書かれている。
その中で注目する文章は、「Do not send a pull request on github.」。

Redmine - Contribute - Redmine

第1回shinagawa.redmineで丸山さんは、Redmineはテストを厳格に行なっているため、単なるパッチだけでなく、テストソースも付属していないと受け入れられない、と言われていた。
全てのオープンソースプロジェクトを知っているわけではないが、丸山さんが言われている内容は普通だろうと思う。

入門Gitを書かれたGitコミッタの濱野さんは、入門Gitの10.9節「オープンな開発プロセス」で、オープンソースプロジェクトのコミュニティで新参者が発言する場合、メールの書き方や議論の仕方、レビューの受け止め方について丁寧に書いている。
その文章を最初読んだ時は、Gitと関係ない内容なのに何故あるのだろうと不審に思ったが、コミュニティという場でパッチをやり取りする時に重要なテクニックの一つなのだ、と思うようになった。

【5】主要ツールに日本人コミッタが存在する利点

Redmineコミッタは丸山さん、Jenkinsコミッタは川口さん、Gitコミッタは濱野さんのように、ITS・SCM・CIというソフトウェア開発の主要ツールに日本人コミッタの名前がちらほら見える。
最近思うことは下記に書いた。

Twitter / @akipii: 今日は大阪でJenkins勉強会があったらしい。最近思うのは3種の神器(例：Redmine・Git・Jenkins)のコミッタに日本人の方がかなりいること。日本人コミッタやコミュニティを通じて日本人開発者の勢いを反映しやすくなる環境ができつつあるのかもしれない。

@haru_iidaさんはITS・SCM・CIをソフトウェア開発の3種の神器と呼ばれたが、今後のソフトウェア開発で重要な役割を担うと思われるツール群に日本人コミッタがいるのは、日本人開発者にとって心強い。
そして、それに関連するように強力なコミュニティも生まれている。
Redmineコミュニティもようやく関西と関東に発足したし、JenkinsはHudsonの頃から関東でコミュニティが活発に活動されていた。先日は関西で初めてJenkins勉強会が開催されて盛り上がったみたい。

そのようなコミュニティに参加して思ったことは、コミッタもコミュニティを必要としていることだ。
ツールの機能改善の要望や運用事例をコミッタも知りたがっている。
コミュニティでユーザとコミッタの間で有意義な議論を行うことで、ユーザの要望をツールに取り込んで、ソフトウェア開発のベストプラクティスがツールの1機能になっていくことで、より強力に開発できるような仕組みが整いつつある。
コミュニティというオープンな場を通じて、ツールの導入や運用を通じて、アジャイル開発の敷居をどんどん下げていければと思っている。