先日 アリエルの開発を支える Trac プラグイン を書きましたが、今日は課題／バグ管理システムの Trac 本体について書きます。
Trac は Edgewall Software が開発した Web ベースの課題管理システムです。修正 BSD ライセンス、オープンソースとして提供されています。いまはどうなっているか分かりませんが、サイト上では Edgewall Software 自身も Trac のコンサルや商用サポートを行っているように書かれています。また、
edgewall.org is a place where a community of software developers collaborate on creating exciting open source software based on the Python programming language.
とあるので Trac をホスティングしているサイト自体は開発者向けに開かれた場所として提供されているようです。Trac Team の情報をみる限り、現在 Edgewall Software の開発者は積極的に関わっていないようです。
Trac 0.12.x から 1.0.x への移行
アリエルでは2013年12月頃に 1.0 系へ移行しました。もう半年以上も前のお話になるため、いまは解決済みの内容もあるかもしれませんが、実際に移行していて遭遇した問題などを紹介します。社内で Trac は業務における一次情報を提供するインフラになっていて、これが止まると業務への影響が大きいため、移行そのものに心理的に慎重になってしまっていました。
アリエルで移行したバージョンは、0.12.1ja から開発中の 1.0.2-trunk にしました。当初は 1.0.1 にしようと試みました。しかし、Genshi 0.7 との組み合わせで #11218, #11261 のエラーが発生したため、当時の 1.0.2-trunk を使うようにしました。その時から 1.0.2-trunk が開発終盤だったのもありますが、移行を阻害するほどのトラブルはなく、結果的には 1.0.2-trunk を選択して良かったように思います。
このブログを書く前にリポジトリを更新して、いまは trac:r12928 で運用しています。
移行中に報告して直してもらったバグ
移行中に発生して Trac Team に直してもらったバグです。修正方法をみていると、Trac の開発チームは最も古いメンテナンスブランチ 0.12-stable にパッチを適用し、その後 1.0-stable, trunk にポーティングするというスタイルを取っているようです。１つのパッチから、一緒に3つのブランチを保守するのはなかなか大変なようにみえます。
DB に postgresql を使っていて、マクロがエラーになったときに postgresql がエラーメッセージとして日本語を含む str 文字列を返し、Genshi がそのエラー文字列を表示するときに Unicode 文字列を期待して UnicodeDecodeError が発生していました。うろ覚えですが、TicketQuery マクロで format を指定せずに col にチケットのカスタムフィールドを指定したときにマクロがエラーになったように思います。0.12 の頃は動いていたので 1.0.x で format 指定が必須になったのかもしれません。
|
|
NG: [[TicketQuery(...,col=summary|owner|custom-field)]] OK: [[TicketQuery(...,format=table,col=summary|owner|custom-field)]] |
この Genshi のエラーはなかなか致命的で、レポート一覧を開いたときに個々のレポートが評価されてエラーになっていました。レポート一覧にレポートが200以上あったため、どのレポートが原因かを突き止めるのが面倒でした。
これは Firefox のみに影響する不具合です。Trac はコメントの入力中の、キーボード入力が一定時間止まったときにプレビューを表示します。どうも Firefox は IME が有効なときに keydown や keypress のイベントを発生しないようです。Firefox で IME を切り替えて入力していると、入力中であってもプレビューが表示されて鬱陶しいといった不具合でした。
移行の全体を通して Genshi が関連するトラブルが多かったように思います。Genshi 自体の問題ではないのかもしれませんが、Genshi のバージョンと Trac のバージョンの組み合わせで発生する問題もありました。通知メールのテンプレートの改行コードに CRLF を使うと、送られてくるメールにバックスラッシュが混入します。Genshi-0.6.1 では再現しません。0.7 ブランチと trunk に修正パッチが取り込まれていますが、そのパッチを含む Genshi-0.7 がまだリリースされていないため、アリエルの環境では Genshi-0.6.1 を使っています。
移行中に遭遇した問題
ここではバグというわけではなく、アリエルでの Trac 利用においてのカスタマイズを紹介します。プラグイン同様、Trac 本体に適用しているパッチも https://github.com/arielnetworks/trac で公開します。それぞれの修正はブランチ単位で管理しています。
EdMax というメーラーを使っている開発者がいて、このメーラーが LF を改行として認識してくれません。Trac の過去のチケット (#2191, #1139) をみると通知メールの改行コードに CRLF を使うように対応したように伺えたのですが、なぜか LF が含まれるユースケースがあるようです。再現方法を調べきれていないため、チケット登録はしていません (1.0-stable-replace-lf-to-crlf-notification) 。多くの開発者が使っている Thunderbird では再現しないのでどっちでも良い気もしますが、RFC 2046 によると CRLF を改行コードに使うのが正しいようです。
- チケットの添付ファイルフィールドの開閉状態のデフォルト設定
チケットの添付ファイルのフィールドの折り畳みのデフォルトが変更されたようです。0.12 では折り畳まれず開いた状態でしたが、1.0 からは折り畳まれるようになったようです。開発者だけでなく、全従業員が Trac を使うのであまり慣れてない人が添付ファイルを見逃してしまうかもしれないという経緯から修正しました (1.0-stable-expand-attachments-in-ticket) 。trac.ini で設定できても良さそうにも思いますが、チケットを作るほどでもないかなと一時対応した状態です。
リポジトリ連携のコメントに更新したファイルを表示する機能拡張です。Trac のマイルストーン 1.1.3 で取り込まれる予定です (1.0-stable-add-config-option-show-changeset-files) 。もともとは TracChangeFileBiffPlugin を作ったとき、ついでにコメントから更新ファイルを一見して分かると便利だというところから出てきたものです。ぱっと見てどういったファイルを更新しているかが分かるのが良いです。
Trac プラグインの非互換な不具合
アリエルでは20～30個ほどのプラグインを使っています。プラグインがたくさんあると、移行のときの互換性が気になりますね。この機にもう使っていないプラグインもいくつか削除しました。
TracTags は準標準的なプラグインです。私が移行しているときは 0.7 の開発バージョンで、且つ DB のテーブルのスキーマを更新したため後戻りができず、このチケットのエラーに悩まされました。いまは 0.7 の正式バージョンもリリースされているので大丈夫です。
DefaultCcPlugin の管理画面で設定をしようとすると、コンポーネントが重複して表示される不具合です。表示だけの問題だったので運用に影響は与えませんが、すぐに直してくれました。
Trac Team へのお礼
移行を通して上述した Trac/TracPlugin の不具合に対応して頂いた Trac Team の Ryan Ollos 氏 と Jun Ōmae 氏 (@jun66j5) に感謝します。おかげで大きなトラブルなく移行できました。ありがとうございました。Trac 開発に協力したい方は What is a good patch? を読んでコントリビュートすると良いと思います。
Trac 開発とロードマップ
せっかくなので Trac の開発状況も少し整理してみましょう。
1.0.2 のマイルストーン
現時点の マイルストーン 1.0.2 によると、94%完了しています。が、スケジュールが17ヶ月遅延とあるように、もはやマイルストーンとして意味を成していません。社内で移行作業を行っていた2013年12月頃も95%前後だったように思います。当時は、ほぼ 1.0.2 の開発が終わってるからいいかと選択したのですが、あれから半年以上経ってもリリースされていない状況です。Trac Team が何もしていないわけではなく、その後もチケットが登録されては直すの繰り返しが続いているようです。
社内で運用していている分には特に困ることはなかったのでみえない所の品質が改善されているのかもしれません。メーリングリストのやり取り をみると、いまあるチケットが close される2週間後あたりを目処にリリースされるそうです。1.0.2 がリリースされたら、この移行記事を書こうと思っていましたが、いつリリースされるか分からないので先に書いてしまいました。
Tracのロードマップ
Road Map によると、3つのバージョンがあります。
- 0.12系: 2010年6月にリリース、LTS (Long Term Support) として保守
- 1.0系: 2012年7月にリリース、バージョン番号を刷新
- 1.1.系: マイナーバージョンの奇数は開発版としてリリース
0.12系は多くのプラグインとの互換性を維持するためにそう簡単には破棄できないようにみえます。プラグインのメンテナンスが追いついていない現状をみると、プラグインが動かないために 1.0 に移行できないケースはあるかもしれません。準標準的なプラグインはほとんど 1.0 に対応しているようにみえますが、メンテナンスされてないプラグインをどうするかが移行の今後の課題のようにみえます。
また TracHacks の運用の問題もあります。プラグインのメンテナーになる方法は Adopting Hacks に記載されています。しかし、メーリングリストにリクエストを送って承認してもらい、Subversion のリポジトリのアクセス権限をもらうといった、いまどきの github で PR を送り合う文化と比べると、手順が面倒なので勢いでメンテナーになるといったことはなさそうに思います。こういったインフラも含めた体制の移行はかなり大変で、いまの Trac コミュニティにそこまでの熱意をもった人がいるのかどうかは微妙なところだと思います。
先日の記事で、当社でもメンテナンスされてない Trac プラグインにパッチを適用したリポジトリを公開しました。使っていて不具合があれば修正はしますが、メンテナーになるほどではないといった開発者のモチベーションを有効活用できない管理体制にみえます。
閑話休題。1.0 以降の開発では、stable と development の2つのブランチに分けることで開発を加速させることを狙いとしています。0.12 から 1.0 のメジャーリリースに2年かかっていることを憂慮しての、それよりも早く同等のリリースを行いたいように伺えます。とはいえ、いま2014年7月で 1.2 がリリース時期すら未定なので意図したように実際には進捗していないようです。マルチプロジェクト対応が 1.1 リリース の目玉機能なので 1.2 の登場は待ち遠しいですね。
Trac とは違う未来の可能性も考えてみます。Trac の課題の１つとして開発やプロジェクトマネジメントそのものが停滞しつつあることは述べました。
さらにオープンソースではあるものの、コミュニティサイトの運営も含め、Edgewall Software が開発／運営しているものというイメージが付くことを問題と捉える人もいます。そんな人たちが vendor-neutral な開発体制への移行を促す意図で発足したのが Apache Bloodhound のようです。Incubator プロジェクトとして発足したときのアナウンスが [PROPOSAL] Apache Bloodhound です。これによると、当初は WANdisco という会社の開発者たちが中心になって開発し始めたようです。
その後、Incubator プロジェクトを卒業して Top-Level プロジェクトに昇格しました。2013年8月にバージョン 0.7 がリリースされています。機能的には、Trac と比較して以下に焦点を当てています。
- マルチプロジェクト対応
- 全文検索機能
- ユーザーフレンドリーなデザイン
- インストールが簡単
Trac 自体の、開発プロジェクトとしての反省から BEP (Bloodhound Enhancement Proposal) という PEP に倣った機能拡張や仕様を提案する方法も取り入れたり、先に述べたマイルストーンの事実上の崩壊にならないよう リリースプロセス を明確にしています。さらに UI スクリーン／情報アーキテクチャ も整備されています。Trac 0.12 からの移行 もできるとありますが、内容をみると Trac 0.12 から 1.0 への移行とあまり変わらないようにみえます。
試しに apache/bloodhoundリポジトリ から trunk をチェックアウトしてインストールしてみました。インストール時に admin ユーザーを作成できるのは簡単で良いですね (いまどき当たり前ですが) 。UI も刷新していて Trac に飽きてきた感のある人には良さそうです。
インストール直後にプラグインを見てると、Bloodhound のツール群は Trac プラグインの1つとしてみえるようです。
目玉機能のマルチプロジェクトです。管理画面上では、プロジェクトではなく プロダクト として管理するようです。UI はよくできています。このプロダクト単位にチケット番号が1から割り当てられます。
当然、チケットの関連付け (BEP-0006) も作れます。いまのところ、プロダクトを跨ぐ関連付けはできないようです。
簡単にインストールして使ってみた限りでは、機能は申し分ないですが、プラグインである点にがっかりしました。
てっきり Apache Bloodhound が Trac を fork して作り直すんだと勘違いしていました。今後どうなるのか分かりませんが、現状では Trac プラグインの再発明と UI を置き換えたもののようにみえます。穿った見方をすれば、Trac の開発が停滞しているのは Edgewall Software の vendor-neutral じゃない性格によるものだと言いたい人たちが Apache Bloodhound という名前に変えたようにも受け取れます。Apache プロジェクトなら vendor-neutral にこだわる開発者も確保できるんじゃないかという問いかけとしてはおもしろいですが、いまのアーキテクチャをみて手伝おうとは思わないでしょう。そこそこの規模の5つのプラグインが、依存関係をもって提供されています。
Trac のエコシステム (プラグイン) を放棄するのは覚悟がいるからそうそうできないでしょう。Trac 開発がいま以上に停滞してしまったら、それなりに需要はあるかもしれませんが、Trac 開発がまた勢いを取り戻せば Apache Bloodhound と Trac のバージョン間での管理コストが増大していき、いずれ Apache Bloodhound のメンテナーがいなくなっていって、いまの TracHacks の状況と同じ歴史を繰り返すんじゃないかという気がします。
もうしばらく Apache Bloodhound のバージョン 1.0 が出るぐらいまで、その動向を伺ってみようと思います。
関連文書:
最近のコメント