適切なサイズのプロジェクトのバグトラッカーは、私にとっては少し簡単なことのように見えます。問題が衝突したり、混乱したりすることなく、数百または数千の問題を整理するのが本当に簡単になります。
ですから、Gitのような、メンテナンスと開発を調整する主要な方法としてメーリングリストを使用している、いくつかの非常に大きなプロジェクトを見ると、少し驚かされます。例:
Git-コミュニティ ページ:
...バグ報告はこのメーリングリストに送ってください。
Debianバグ追跡システム 、Wikipediaごと:
...そのユニークな機能は、バグレポートを編集するためのWebインターフェイスの形式がないことです。すべての変更は電子メールで行われます。
最新のバグトラッカーの多くは、電子メール(あなたが見ているバグ、またはあなたに割り当てられたバグに関するコメントや通知を受け取ることができます)だけでなく、バージョン管理システム(コミットは問題の解決としてマークすることができます)などと非常によく統合されています。)。これの多くは、メーリングリストを使用して手動で行う必要があり、興味のないバグに関する大量のメールが届きます。
では、Webベースのバグ追跡システムと比較した場合のメーリングリストの主な利点は何でしょうか。なぜいくつかの大きなプロジェクトはメーリングリストしか使わないのですか?
あなたが観察する好みは GNU Coding Standards で明確に述べられた推奨の自然な結果のように見えます。以下の引用でわかるように、メールでバグを報告することをお勧めします(太字観察に直接対応する部分をマークしました)。
4.7.2
--help
標準の
--help
オプションは、プログラムを呼び出す方法の簡単なドキュメントを標準出力に出力し、正常に終了します。これが表示されたら、他のオプションと引数は無視する必要があり、プログラムは通常の機能を実行できません。
‘--help’
オプションの出力の終わり近くに、バグレポートのメールアドレスを示す行を配置してください、パッケージのホームページ(通常は‘http://www.gnu.org/software/pkg’
、およびGNUプログラム。形式は次のようになります。Report bugs to: mailing-address pkg home page: <http://www.gnu.org/software/pkg/> General help using GNU software: <http://www.gnu.org/gethelp/>
他の適切なメーリングリストやウェブページについて言及しても問題ありません。
上記の優先順位は、電子通信の形式としての電子メールの普遍的な受け入れを反映しています。上で提案したような--help
メッセージを読むユーザーは、バグを見つけた場合の対処方法を簡単に理解できるはずです-郵送は簡単です。
Issue Trackerは、プロジェクトで作業する開発者にとっては優れている(そしてはだと思う)かもしれませんが、より広い聴衆にとっては、特に幅広い多様性と違いを考慮して、それを使用する方法を提示して説明することは難しいでしょう異なる 問題追跡システム 。
1つのプロジェクトではBugzillaを使用でき、別のプロジェクトではJIRAを使用し、3番目のプロジェクトでは... [〜#〜] gnats [〜#〜] などを使用します。これをすべて提示する方法はありません "動物園」は、標準的で統一された方法で
Report bugs to: mailing-address
上記のメモは、プロジェクトで内部的に課題追跡を使用してはならないという意味ではありません。 関連する質問に対する優れた答え で説明されているように、
バグトラッカーはyourの便宜のためであり、顧客のためではありません。あなたが彼らの電話または電子メールの問題を取り上げて自分で入力するのに煩わされない場合、彼らはどのように感じますか?
問題を入力して手動でクライアントに割り当てることができる必要があります...
特にGitには、歴史的な理由があります。GitはLinuxハッカーのためにLinuxハッカーによって開始され、Linux自体と同じ開発モデルとツールを使用しています。ただし、LinuxはWWWよりも古いため、Linuxを起動したときはwere noweb-based issue trackersという理由でなかったweb!
その結果、Linuxコミュニティはバグレポートやコードレビューを電子メールで処理するための非常に効率的なツールとワークフローを開発しており、Gitプロジェクトを開始したときに、すべての作業を破棄してゼロから始める理由はありませんでした。
Gitの場合:
メーリングリストでは、ある種のバグ追跡システムの使用を提案する議論がいくつかあります。これらのイニシアチブはすべて混乱しているように見えるため、Gitがバグトラッカーを使用しない理由は、おそらくほとんどの貢献者が役に立たないと考えているためです。
メーリングリストへの投稿 で、Jumio C Hamano(Gitのメンテナー)は、バグトラッカーがあまり役に立たないと感じた理由を要約しました。投稿全体を含めたくはありませんが(かなり長いです)、要約すると次のようになります。
Debianはバグ追跡を使用します。デフォルトのインターフェースは電子メールです。そして便利です。現在のDebianプロジェクトリーダーであるLucas Nussbaum 数日前に投稿 :
debbugsは、Debianバグ追跡システム(BTS)の背後にあるソフトウェアです。 GNUプロジェクトでも使用されます。古いスタイルと見なされがちですが、各バージョンのバグのステータスの追跡やパッケージのブランチなど、いくつかのユニークな機能を備えています)、または電子メールを介してすべてのやり取りを実行する機能により、オフラインまたは接続が不十分な環境で非常に簡単に作業できます。
最後の部分はキラー機能です-飛行機を降りるまで、ローカルのメールキューにそれらのレポートをキューに入れてください!
頭に浮かぶメーリングリストの欠点の1つは、フォーラムはカテゴリとサブカテゴリに分割できるが、メーリングリストは分割できないことです。これは、メーリングリストをいくつかのメーリングリストに分割することでエミュレートでき、ユーザーは適切なフィルターを使用して、各メッセージを対応するフォルダー(各フォルダーはカテゴリ)に配置できます。 Webフォーラムでは、これは自動的に行われます。