web-dev-qa-db-ja.com

GitやDebianなどの一部の大きなプロジェクトで、課題追跡を使用せずにメーリングリストのみを使用するのはなぜですか？

適切なサイズのプロジェクトのバグトラッカーは、私にとっては少し簡単なことのように見えます。問題が衝突したり、混乱したりすることなく、数百または数千の問題を整理するのが本当に簡単になります。

ですから、Gitのような、メンテナンスと開発を調整する主要な方法としてメーリングリストを使用している、いくつかの非常に大きなプロジェクトを見ると、少し驚かされます。例：

  • Git-コミュニティ ページ：

    ...バグ報告はこのメーリングリストに送ってください。

  • Debianバグ追跡システム 、Wikipediaごと：

    ...そのユニークな機能は、バグレポートを編集するためのWebインターフェイスの形式がないことです。すべての変更は電子メールで行われます。

最新のバグトラッカーの多くは、電子メール（あなたが見ているバグ、またはあなたに割り当てられたバグに関するコメントや通知を受け取ることができます）だけでなく、バ​​ージョン管理システム（コミットは問題の解決としてマークすることができます）などと非常によく統合されています。）。これの多くは、メーリングリストを使用して手動で行う必要があり、興味のないバグに関する大量のメールが届きます。

では、Webベースのバグ追跡システムと比較した場合のメーリングリストの主な利点は何でしょうか。なぜいくつかの大きなプロジェクトはメーリングリストしか使わないのですか？

project-managementcommunicationissue-trackingemail
66
naught101

あなたが観察する好みは 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の便宜のためであり、顧客のためではありません。あなたが彼らの電話または電子メールの問題を取り上げて自分で入力するのに煩わされない場合、彼らはどのように感じますか？

問題を入力して手動でクライアントに割り当てることができる必要があります...

45
gnat

特にGitには、歴史的な理由があります。GitはLinuxハッカーのためにLinuxハッカーによって開始され、Linux自体と同じ開発モデルとツールを使用しています。ただし、LinuxはWWWよりも古いため、Linuxを起動したときはwere noweb-based issue trackersという理由でなかったweb！

その結果、Linuxコミュニティはバグレポートやコードレビューを電子メールで処理するための非常に効率的なツールとワークフローを開発しており、Gitプロジェクトを開始したときに、すべての作業を破棄してゼロから始める理由はありませんでした。

30
Jörg W Mittag

Gitの場合：

メーリングリストでは、ある種のバグ追跡システムの使用を提案する議論がいくつかあります。これらのイニシアチブはすべて混乱しているように見えるため、Gitがバグトラッカーを使用しない理由は、おそらくほとんどの貢献者が役に立たないと考えているためです。

メーリングリストへの投稿 で、Jumio C Hamano（Gitのメンテナー）は、バグトラッカーがあまり役に立たないと感じた理由を要約しました。投稿全体を含めたくはありませんが（かなり長いです）、要約すると次のようになります。

  • 解決済みの問題に関する情報のみを探している場合は、リストアーカイブの検索は、バグトラッカーの検索と同様に機能します。
  • あなたが本物のバグを報告し、人々がそれを世話したいと思っているなら、リストもうまくいきます。
  • 誰も問題に取り組むことに興味がない場合、バグ追跡システムでさえ、それは亀裂を通り抜けます。
  • バグトラッカーは、メンテナンス、新しいバグの定期的なチェック、バグの修正などの必要なもう1つのシステムです。
17
sleske

Debianはバグ追跡を使用します。デフォルトのインターフェースは電子メールです。そして便利です。現在のDebianプロジェクトリーダーであるLucas Nussbaum 数日前に投稿 ：

debbugsは、Debianバグ追跡システム（BTS）の背後にあるソフトウェアです。 GNUプロジェクトでも使用されます。古いスタイルと見なされがちですが、各バージョンのバグのステータスの追跡やパッケージのブランチなど、いくつかのユニークな機能を備えています）、または電子メールを介してすべてのやり取りを実行する機能により、オフラインまたは接続が不十分な環境で非常に簡単に作業できます。

最後の部分はキラー機能です-飛行機を降りるまで、ローカルのメールキューにそれらのレポートをキューに入れてください！

6
Dominik George
  • 9歳児を締め出します。
  • フォーラムごとに個別のアカウントを作成する必要はありません。
  • [マイナー]さまざまなメーリングリスト全体で一貫したユーザーエクスペリエンスと、新しいリストに登録する際の学習曲線がゼロ。
  • オフラインで動作します。インターネットに接続してメールのバッチをダウンロードし、ハイキングに行き、母なる自然を楽しみながら返信を書き、後で送信することができます。
  • GPGを介したメールの暗号化や署名を許可します。
  • 分散型-フォーラムがクラッシュした場合でも、コピーは保持されます。また、改ざんに強く、悪意のあるモデレーター/ハッカーはあなたが言ったことを簡単に改ざんできません。誰も履歴を元に戻すことはできません。
  • フィルター、フォルダー、および電子メールクライアントのすべての高度な組織機能を許可します。
  • 「プッシュ通知」-メールクライアントを開いたままにして、新しい返信の通知を受け取ることができます。
  • それらすべてを統括する1つの場所-異なるサイト間をジャンプする必要はありません。
  • Webに関連するすべてのセキュリティの脆弱性（html/javascript/injectionsなど）に対する耐性
  • 膨らみなし-バッジ、派手な動く署名、広告、ウェブビーコン、JavaScript膨らみはありません。それはすべて単純で、要点です-議論。
  • LAMPセットアップよりもサーバーの負担が少ない。

頭に浮かぶメーリングリストの欠点の1つは、フォーラムはカテゴリとサブカテゴリに分割できるが、メーリングリストは分割できないことです。これは、メーリングリストをいくつかのメーリングリストに分割することでエミュレートでき、ユーザーは適切なフィルターを使用して、各メッセージを対応するフォルダー（各フォルダーはカテゴリ）に配置できます。 Webフォーラムでは、これは自動的に行われます。

4
Hello World