なぜGitやDebianのようないくつかの大きなプロジェクトでは、メーリングリストのみを使用し、問題トラッカーを使用しないのですか?


65

まともなサイズのプロジェクトのバグトラッカーは、私にとっては簡単なことのように思えます。問題が衝突したり混同したりすることなく、数百または数千の問題を非常に簡単に整理できます。

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

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

    ...バグレポートはこのメーリングリストに送信する必要があります。

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

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

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

それでは、Webベースのバグトラッカーに対するメーリングリストの主な利点は何ですか?一部の大きなプロジェクトでメーリングリストのみが使用されるのはなぜですか?


2
はい、そうではありません。Gitはメーリングリストを使用しています。それらの本当に大きなプロジェクトの例。それ以外の場合、質問は「Gitはメーリングリストを使用します。なぜですか?」その場合には、イェルクWミッタークの答えは適してい...
シヴ山のドラゴン

1
Hrm、まあ私はもっとあると思っていました... Debianはメーリングリストよりも複雑ですが、メールベースのシステムを使用しています。わかりましたが、主なポイントは「バグトラッカーよりもメーリングリストを使用する利点は何ですか?」です。答えが「何もなければ、git開発者は単なるラディット」です。
-naught101

@ naught101:なぜあなたはそれを見たときに吹き飛ばされるのですか?Debian 不安定版は、パッチを適用する必要のあるリモートルートエクスプロイトを見たり、簡単に6か月間再起動する必要なくインストールおよび使用できます。これはDebian の不安定バージョン用です。4桁の稼働時間に達したDebianサーバーをロックダウンしました(その期間中にセットアップに影響する再起動を必要とする単一のリモートルートエクスプロイトではありません)。これらの人たちは最新の技術流行を使用していないかもしれませんが、彼らは明らかに正しいことをしています。Debianの安定性のために、いつでもウェブバグトラッカーを放棄します。
セドリックマーティン

2
@CedricMartin:わかっています、同意します。メーリングリストのバグ追跡は、一部のチームでは明らかに適切に機能しますが、それでもバグトラッカーよりも簡単ではないようです。しかし、中核プロジェクトの開発者にとっては、その差は非常に小さいように見えるかもしれないと考えてきました。彼らはとにかく起こっていることのほぼすべてに従うのです。しかし、新規参入者にとっては、メーリングリストを理解することはほぼ不可能であるため、プロジェクトの適合性の簡単な概要を把握することはできません。バグトラッカーを使用すると、新しいユーザー/開発者はプロジェクトがどのように動いているかをすばやく把握し、コアチームがどのような改善を重要と考えているかを把握できます。
naught101

Greg Kroah-Hartmanは、この議論の一部としてLinuxカーネルに関連しているため、これについての見解を持っています。具体的には:「ありません NO githubの/ヘリット/ gitoriousモデルは、カーネルのためにすべてうまくいくやり方は、私たちが仕事れるスケールはこれらのツールによって処理することができるよりも全く違うレベルである...実際には他にはありません。 2か月ごとに10000個のパッチを安定したリリースで、ピアレビュー付きで、3000人以上の開発者と一緒に現在の方法以外で処理する既知の方法。」
naught101

回答:


45

観察する好みは、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/>

他の適切なメーリングリストやWebページに言及してもかまいません。

同様に、上記の好みは、電子通信の形式としての電子メールの普遍的な受け入れを反映しています。--help上記のようなメッセージを読んでいるユーザーは、バグを見つけた場合の対処方法を簡単に理解できるはずです-郵送は簡単です。

課題トラッカーはあるかもしれない(と私は考えている)プロジェクトで働く開発者のためのより良い、より広い聴衆のためには、特に考慮に多種多様と異なるとの違い取って、提示し、それを使用する方法を説明するのは難しいだろう問題追跡システムを

1つのプロジェクトはBugzillaを使用でき、別のプロジェクトはJIRAに固執し、3つ目はGNATSなどに固執します。など。

Report bugs to: mailing-address


上記の注意は、プロジェクトが課題トラッカーを内部で使用するべきでないことを意味しません。関連する質問に対する優れた回答で説明されているように、

あなたのバグトラッカーはあなたの便宜のためであり、あなたの顧客のためではありません。電話やメールの問題を自分で入力してわざわざ入力できない場合、どのように感じますか?

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


3
素晴らしい答えです!メールは、より良い問題追跡システムよりも知られており、容易に理解するために(誰もが言っているのではないどの電子メール「取得」:P)
アンドレス・F.

21
また、GNUのアドバイスは古く、WebおよびWebベースの課題追跡よりもずっと古いものです。
ロスパターソン

@RossPatterson私はそれを考えていました。しかし、多くのURLが含まれていることを考慮すると、Webよりも古い可能性は低いようです
...-naught101

6
@gnat:そのリンクされた答えがとても素晴らしいのは、「あなたにとって簡単なら、そのようなものをすぐに入力できる」という部分です。電話サポートの資金がないため、これは多くのオープンソースプロジェクトの鍵となります。メーリングリストは、バグ報告ユーザーとしての私にとっては消極的なものです。応答にサインアップする必要はありません。バグトラッカーを使用すると、システムに問題があることがわかります。後で戻って検索し、更新されたかどうかを確認できます。メーリングリストでは、これは非常に優れたWebベースのリストトラッカーがない限り困難です。
naught101

1
@ naught101 Webより古いわけではないかもしれませんが、Webベースのトラッカーよりも確かに古いです
sakisk

30

特にGitには、単純な歴史的理由があります。GitはLinuxハッカーのためにLinuxハッカーによって開始され、Linux自体と同じ開発モデルとツールを使用します。ただし、LinuxはWWWよりも古いため、Linuxが起動されたとき Web が存在しなかったため、Webベースの問題トラッカーはありませんでした

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


3
WWWはLinuxよりも先だと思いました。やや。それらはほぼ同時に、異なる人々のグループによって非常に行われました。90年代半ばまでは、実際に離陸しませんでした。
ドナルドフェローズ

6
わかりましたが、Linuxカーネルにはバグトラッカーbugzilla.kernel.orgがあります。明らかにそれはそれほど大きな障壁ではありません。
naught101

7
-1 GitはWebよりもかなり若いです。Vintage2005。当時はもちろんBugzillaを含むたくさんの課題追跡がありました。Linusは課題追跡を好まないだけで、彼の言葉はその環境における法律です。
ロスパターソン

6
@RossPatterson-LinuxはGitではなくWebよりも古いと彼は言った。基本的に彼が言ったことを繰り返したので、あなたのコメントは反対票を正当化するとは思わない。
beatgammit

2
@tjameson後知恵では、あなたは正しい。ニュートラルに戻ります。
ロスパターソン

17

Gitの場合:

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

ではメーリングリストに投稿し、彼はバグトラッカーは非常に便利ではないと感じる理由を、Junio C浜野(Gitリポジトリのメンテナ)がまとめました。投稿全体を含めたくはありません(かなり長いです)が、要約すると次のようになります。

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

5
良い答えですが、あなたの3番目のポイントは電子メールの主な欠点であると主張します。バグを修正するのが難しく、現在の開発者が怠けている場合、問題追跡システムのエントリよりもかなり埋もれます。これは、人々がそこに知っていないという理由だけで、特定のバグが修正されることはありません意味するかもしれない
TheLQ

1
@TheLQ:はい。しかし、明らかにそれはいくつかのプロジェクトが喜んで取るリスクです。公平を期すために、gitはバグトラッカーがなくてもかなり堅実なソフトウェアです。
sleske

1
@TheLQ:既知のバグ(および関連するスレッド)をすべて記載した単純なWebページでそれを解決できないでしょうか?リンクがアーカイブスレッドを指すことを除いて、これにもの。
ハローワールド14

1
@HelloWorld:まあ、それは(単純な)課題追跡システムです。そして、ちょうど問題追跡のように、誰かがそれを管理する必要があります...
sleske

購読者ではない間に送信されたメールのオフラインコピーを取得する良い方法はありますか?
PSkocik

6

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

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

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


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

思い浮かぶメーリングリストの欠点の1つは、フォーラムがカテゴリとサブカテゴリに分かれているのに対し、メーリングリストはそうではないことです。これは、メーリングリストを複数のメーリングリストに分割することでエミュレートでき、ユーザーは適切なフィルターを使用して各メッセージを対応するフォルダー(各フォルダーがカテゴリー)に入れることができます。Webフォーラムでは、これは自動です。


なぜ人々は問題を追跡するためにWebベースのバージョンを作成することを主張するのですか(ところでこの質問はすべてではありません)、別の質問で議論されています:ユーザーにまともで有用なバグレポートを書くことユーザーが改善...」
gnat 14

ありがとうございました。しかし、これは下票を正当化しますか?この答えの主なトピックはMLの利点であり、元の質問にかなりよく答えます。「ウェブフォーラム」の暴言を削除しました。
Hello World 14

2
この回答で言及されている不利な点は、実際、ほとんどの開発者メーリングリストに固執することを根本的に妨げています。彼らはすべてを送信するので、バグを報告した後、私は通常わずか2週間後に退会します。バグトラッカーは、特定のバグレポートを購読させてこの問題をうまく解決します。
ローマンスターコフ

6
訂正:25歳の子供を締め出します。つい最近になって、これらのメーリングリストが実際のプロジェクトに貢献する仕組みを学びました。そして、私はそれが嫌い!
Ciro Santilli新疆改造中心法轮功六四事件

2
「フォーラムごとに個別のアカウントを作成する必要はありません。」-スパムを防ぐために、リストに登録する必要があります。しかし、それはすべてのメールを購読しています。そのため、「スパム」をサブスクライブしてオプトアウトし、CCまたはTOを維持するためのリクエストを追加する必要があります。bugzillaと比較すると、やることがはるかに多くなります。
マチェイピエチョトカ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.