私たちは trac を使用しており、本当に満足しています。ただし、すぐに使用できる trac は、単一プロジェクト環境にのみ最適です。それにもかかわらず、複数のプロジェクトでそれを機能させるために人々がとるさまざまなアプローチと、それらの経験について聞いてみたいと思います. おすすめのプラグインはありますか？パッチ、微調整などはありますか? trac のすべての機能に加えてマルチプロジェクトのサポートを提供する、まったく異なるバグ追跡システムを使用しているのでしょうか?
私たちは最近、自分たちで 2 つ目のプロジェクトを管理し始めました。これは通常は問題なく動作しますが、いくつかの欠点もあります。特に、両方のプロジェクトで使用される共通のライブラリ コードを記述したために 2 つのプロジェクトが重なっている場合です。これをどのように処理しますか？
（この投稿への回答として、私たち自身の現在のアプローチを添付します。）
私たちが採用したアプローチは、新しいプロジェクトごとに別の trac 環境を作成し、InterTracリンクをセットアップして、2 つの間の相互参照をより簡単にすることです。[inherit] ディレクティブを介して共通のベースTrac.iniファイルも使用します。
質問で言及されている共有コードのあいまいさの問題に加えて、これには、プロジェクトとワークフローの性質に応じて、影響する場合と影響しない場合があるいくつかの欠点があります。
私たちが従った別の方法は、さまざまなプロジェクトをコンポーネントとして構成することです。
SVNリポジトリとホームwikiページを共有していますが、マイルストーン機能は使用していません。プロジェクトが異なるモジュール（この場合は1つだけ）を持つのに十分な大きさである場合、各モジュールをプロジェクトではなくコンポーネントとして構成します。
約 1 年前にSimpleMultiProjectPlugin (1 つの Trac インスタンスで複数のプロジェクトをサポート) が実装されました。>= Trac 0.12 で動作します。新しいチケット フィールド「プロジェクト」を追加し、タイムラインとロードマップ ページを複数のプロジェクトのフィルターで拡張し、そのバージョン、コンポーネント、およびマイルストーンをプロジェクトにマップします。
ここでも同じように感じます。Trac は適切に設定されると非常に便利です。また、コードに触れることなく簡単にハッキングできます。ウィキの構文が、マークダウンのようにもっと一般的なものになればいいのにと思います。
1 つの Trac インスタンスを使用するというアプローチを採用しました。タイトな ACL を使用する必要はありませんでしたし、使用したくもありませんでした。これには、開発者のすべてのアクティビティを 1 か所に保持できるという利点があります。
プロジェクトを分離するために、基本的にバグをさまざまなマイルストーンに割り当てています。すべてのプロジェクトには、短期および長期のマイルストーンがあります。短期は実際のバグの修正に使用され、長期はメジャー リリースに使用されます。
他の「新しいチケット」フィールドのほとんどは削除され、「タイプ」フィールドと「重大度」フィールドは維持されますが、これらはすべてのプロジェクトで同じです。
レポートは基本的に「マイ チケット」に限定されており、「レポートを表示」ボタンはチケットに直接アクセスできるように調整されています。
ワークフローは、QA が修正を保証できるように、中間の「テスト」ステータスを追加するようにも調整されています。
電子メールの構成は、開発者が実際に割り当てを読み取れるように、メールボックスがあふれないように調整されています。
これで、非常に効率的なツールが完成しました。うまくいくまでには少し時間がかかりましたが、ハックして Google で検索する方法を知っていれば、簡単に変更できます。