私たちは皆、Linus TorvaldsがBitkeeperの問題のためにGitを作成したことを知っています。 （少なくとも私にとって）私が知らないのは、その前に問題/チケット/バグを追跡する方法です。私は試しましたが、興味深いものを取得できませんでした。このトピックについて私ができる唯一の議論はこれです。LinusはBugzillaの使用に関する懸念を共有しています。。
推測：- 人々が初期段階でバグを追跡する最も簡単な方法は、チケットを自分の四半期に置くことです。しかし、ノイズが良いバグよりも大きくなるとすぐには拡張されないと確信しています。
私はBugzillaを見て使ってみましたが、正しい「キーワード」を知らないと時々詰まることがあります。メモ:私は特に初期（1991-1995）に興味があります。に慣れる問題を追跡してください。
2つの手がかりを見ました。」カーネルSCMの凡例「、そして」常識：Gitはいつ自分のホスティングになりましたか？しかし、これらのどれも初期のカーネルバグトレースについて言及していません。
私は周りを検索しましたが、1991-1992年に登場したFOSSバグ追跡ソフトウェアが見つかりませんでした。 Bugzilla、Request-tracker、その他のツールははるかに後でリリースされたため、段階的に廃止されているようです。
重要な問題
- それでは、当時、Linusとサブシステム管理者、ユーザーはどのようにバグを報告して追跡しましたか？
- バグトラッキングソフトウェアを使用したり、バグブランチを作成したり、その中のバグに関する問題やディスカッションを手動で送信したり（費用がかかり、痛みを伴う）、または単に電子メールを使用しますか？
- ずっと後、Bugzillaが登場し（1998年に最初にリリースされました）エラーの事実を事後に報告する主な方法。
過去に何が起こったのかをより明確に理解することを楽しみにしています。
答え1
最初に何か（パッチやバグレポート）を提供する必要がある場合は、Linusにメールで送信できます。これはリストにメールを送信する方法で進化しました（リストが作成される前[email protected]）。kernel.org
バージョン管理はありません。 Linusは時々FTPサーバにtarballを置く。これは「ラベル」と同じです。最初に利用可能なツールはRCSとCVSでしたが、Linusはそれを嫌っていたので、誰もがパッチをメールで送りました。 （ありますリヌスの説明彼がCVSを使用したくない理由について。 )
Bitkeeper以前は、他の独自のバージョン管理システムがありましたが、Linuxの分散型ボランティアベースの開発のために利用できなくなりました。パッチが独自のバージョン管理システム（ライセンスは数千ドルから始まる）を通過する必要がある場合、バグを発見したばかりの人はパッチを送信しません。
Bitkeeperは両方の問題を解決します。 CVSほど集中化されておらず、フリーソフトウェアではありませんが、カーネルの貢献者は無料で利用できます。そのため、しばらくは十分に良くなりました。
今日のgitベースの開発にもかかわらず、メーリングリストはまだ最も重要な場所です。何かを貢献したい場合は、もちろんgitを使用して準備できますが、マージする前に関連するメーリングリストで議論する必要があります。 Bugzillaは「プロフェッショナル」に見え、専門的でない人々の説得力はバグレポートを吸収するために存在します。本物それの一部になりたいです。
古いバグ報告の指示を見るにはLinux 履歴ストア。 （これはgitが存在する前のすべてのバージョンを含むgitリポジトリです。ほとんどの場合、tarballで再構築されるため、バージョンごとに1つのコミットが含まれています。）興味のあるファイルには、、、およびがREADMEありMAINTAINERSますREPORTING-BUGS。
Linux-0.99.12 readmeで見つけることができる興味深いものの1つは次のとおりです。
- if you have problems that seem to be due to kernel bugs, please mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup. The mailing-lists are
useful especially for SCSI and NETworking problems, as I can't test
either of those personally anyway.
答え2
これらのプロセスはニュースグループ（USENET）と（主に）Eメールを使用します。バグはスレッドとして「存在」し、タイトルに「」または「」を追加するのが[BUG REPORT]一般的な慣例です。LINUX BUG REPORTエラーIDがありません。一般的なユーザーベースを考慮すると、バグレポートにはパッチが伴うことがよくあります。長い間忘れられたソフトウェアツールを使用してきました：（ibug以下を参照）何よりもdiff+ patch。
~からLinuxのインストールと起動（1994年1月、v2.0アーカイブのコピー） >
2.6 The Design and Philosophy of Linux When new users encounter Linux, they often have a few misconceptions and false expectations of the system. Linux is a unique operating system, and it is important to understand its philosophy and design in order to use it effectively. Time enough for a soapbox. Even if you are an aged UNIX guru, what follows is probably of interest to you. In commercial UNIX development houses, the entire system is devel- oped with a rigorous policy of quality assurance, source and revision control systems, documentation, and bug reporting and resolution. [...] With Linux, you can throw out the entire concept of organized development, source control systems, structured bug reporting, or sta- tistical analysis. Linux is, and more than likely always will be, a hacker's operating system.(4) [...] For the most part, the Linux community communi- cates via various mailing lists and USENET newsgroups. A number of con- ventions have sprung up around the development effort: for example, any- one wishing to have their code included in the ``official'' kernel should mail it to Linus Torvalds, which he will test and include in the kernel [...]
1992年
以下は、1992年12月（0.98.6）現在のcomp.os.linuxのバグレポートと修正です。 https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion
非常に初期にはメールリストがありました。ml-Linux-バグ(1992/1993)、ここから初期FAQ内部に余裕ソフトウェアリリース1.01：
VI.01) $#@! を Linux に移植した後、正しく実行されないようです。エラーを報告するにはどうすればよいですか？
[...]私」[Eメール保護]バグレポートのリストが削除されました。通常、次のパッチレベルまたはバージョンで修正されます。
「linux-kernel」の電子メールリスト（元のバージョンで実行されているvger）、ニュースグループalt.os.linux、およびcomp.os.linux（すぐに1993年階層に分割）。
これ初期Linux FAQ（v1.11 1992年11月）comp.os.linuxでは、Linusに直接電子メールを送信することをお勧めします。
1992年マットウェルシー（Linuxの実行、Linux聖書、TLDP)発表するibug電子メールで送信されるエラーレポートを生成するのに役立ちます（つまり、Linuxでは、電子メールを送信するのに十分なネットワークが不足していたため、この機能を実行できませんでした）。
Eメールエラーレポートテンプレートlinux.tempまた、comp.os.linuxにも定期的に公開され、バグレポートは次のように更新されます。テンプレートの更新linux.fix.temp。
まだ一つあります。パッチストア（FTP）、私が知っている限り、これは主に（排他的ではありませんが）Linuxに移植されたプログラムへのパッチです。
1993-1994
カーネルソースコードのCVSコピーは一般的であり、私が見つけることができる最も速いのは、カーネル0.99.14時代のDirk Steinbergです。これ最初の発表linux-activistsで1993年1月のコンテンツを見つけることができます。あなたはまだ見つけることができますアーカイブされたコピー（1994）。 DirkはCVSのcvsバイナリとlibcソースコードも維持しています。
CVSは現代的な意味でバグを追跡するためには使用されていませんが、一部の開発者はCVSを使用することを好み、パッチはcvsで生成されたdiffとして送信されることがよくあります。
1995-1996
この頃（1995年10月）、David S. MillerはLinuxカーネルのSPARCポートにCVSを使用し始めました（Linux/SPARC ポート）。 1996年2月まで、他のいくつかのカーネル開発者は独立してCVSを使用してlinux-kernelのパッチを追跡しました。このスレッドそしてこのスレッド：アランコックス、スティーブンツイーディ、ケイヘニングソン。 （2番目のスレッドは、Russ NelsonがLinusのCVSに対する嫌悪感を直接表現したと報告しています。）
1997-1998
1998年4月、リヌスの2番目の子供が生まれた直後、linux-kernelに見られるように、CVSに問題が再発しました。このサブスレッド（LinusはCVSに対する懸念を直接繰り返しました。）
1997年12月、アンドルテリガル公開されたジッタバーグ、Webベースのバグトラッカーです。 1998年6月まで、「linux-patches」JitterBugが開発されました。linux-kernelでAlan Coxが提供。私が知っているのは、これがLinusと他の主要開発者が使用した最初の実際のバグ追跡システムでした。残念ながら、「linux-patches」インスタンスはオンラインではなくなりました。
1998年9月bitkeeperがLinuxカーネルで初めて昇格しました。著者：ラリー・マクエボーイ
1999年以降
渡す1999/2000 lml FAQ（オリジナル）vgerのCVSツリーを参照して始めます（質問1-16）。これは当時Andrew Tridgellによって維持されました。
2001年12月まで、Jitterbugは人気を失いました。このLinuxカーネルを参照してください。ワイヤー、Linus、Alan Cox、および他の多くの人々がその理由について議論しています。
2002年1月まで、Linusはビットキーパーに興味を持っています。（PowerPC Linuxカーネルチームはすでに使用しています）。
2002年2月LinusはBitkeeperを使い始めます。2.5 開発ツリーの場合。
2002年11月、OSDLは2.5ツリー用のLinux Bugzillaをホストしました。発表される。 （まだ読んでいない場合バグジラリンク質問は今読んでください。古いLinusの暴言が含まれています。）
2005年4月LinusはBitKeeperから脱退すると発表した。、約。gitその人が最初に名前に言及した。すぐにgitはすでに独自のホスティングが可能です。その後、LinusはBitKeeperの使用をやめ、gitをカーネルとして使用し始めました。
2008年12月なお、立つ細工パッチトラッカーLinuxカーネルがリリースされました、メーリングリストと統合され、パッチおよびその後のパッチを追跡するSCCSに依存しないWebベースのパッチトラッカー。この方法は今日まで使用され続けており、約40のリストがこのように追跡されています。https://patchwork.kernel.org/しかし、すべてがアクティブになっているわけではありません。
引用する
便利な参考資料：
- 分散タスクの性質：Linuxカーネルのケース（ムン・ジェユン、リースプロール） http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710（2000年11月）
- Linuxのバグ報告ガイドライン（1992年7月） http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
- Kenneth R. Saborioの重要なLinux投稿/電子メールアーカイブ： http://www.informatica.co.cr/linux/index.htm(1991-2005)
- 今日（2014年11月）から1995年までのLinuxカーネルアーカイブ http://lml.iu.edu/hypermail/linux/kernel/ （悲しいことに、最初の電子メールは、管理者Chris Dentが初期のアーカイブを失ったと発表した1995年6月に送信されました...） ランカ・メレアーカイブは次のように返されます。1996年
- tsx11用linux-devel 1993-1994のスニペット http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux-devel/ （URLとファイルの日付は無視してください）
- バージョン管理ツール：LinuxカーネルのCVSからBKへ、Sjaikh、Cornford (c. 2003)
- これも見てくださいハッカーニュースGitの10周年が近づくにつれて、テーマ（2015年3月）：https://news.ycombinator.com/item?id=9263336
答え3
バグレポートが自分の開発をどのように処理するかを知ることができますgit。
彼らはバグ追跡ソフトウェアを使用しません。バグが報告され、以下で議論されました。メーリングリストの開発。これは驚くべきことですが、うまくいきます。
特定のバグ追跡ソフトウェアの使用に関する質問や提案が頻繁に出てくるので、gitメーリングリストのアーカイブを検索してこれについて多くを学ぶことができます。
これは「十分に良いバグトラッカーが見つかりませんでした」ではなく、「まだ十分に良いバグトラッカーが見つかりませんでした」に関するものです.
しかし、「私たちにはより良い方法があります」とは限りません。
このアプローチを使用すると、プロジェクトまたはサブプロジェクトの管理者（シニア開発者など）が開発リストの非公式コーディネーターとして重要な役割を果たすことができます。
バグを処理することはその一部であり、このようにバグを管理することは簡単な作業のようには見えないかもしれません。これは確かにその役割を果たす人のスキルに依存します。
このアプローチの最も正式な部分は、毎週の状態要約メッセージです。
各ブランチで現在行われている作業を簡単な項目として一覧表示します。 git開発の例については、ミラーメーリングリストのニュースgmane.comp.version-control.gitグループを参照してください。git.gitがすること
私はこれを確かに言うことができます。これをうまく行う管理者がいる場合は、非常にうまく機能します。
たとえば、私は非常にバグトラッカーの導入が変更のオーバーヘッドを償却した後でも、長期的に実装の機能と品質にプラスの生産性に影響を与えると驚くことでしょう。
Linuxカーネルの場合、これまでgitが行った操作と似ています。
Linuxカーネル開発のための開発メーリングリストは確かに重要です。しかし、gitのように中央の場所にリストはありません。ファイルシステムやネットワーキングなどの別のサブトピックのリストがあります。
別々のトピックが存在し、主に別々の開発者によって処理されるため、一部のグループは実際にそのグループに限定されたツールを使用できます。