Linux Kernelプロジェクトは初期のバグをどのように追跡しましたか？

私たちは皆、Linus TorvaldsがBitkeeperの問題のためにGitを作成したことを知っています。（少なくとも私には）知られていないのは、それまでに問題/チケット/バグがどのように追跡されていたのですか？試しましたが、何も面白くありませんでした。私がこのテーマについて議論できたのは、LinusがBugzillaの使用に関する懸念を共有したこのディスカッションだけでした。

憶測： -人々が最初の段階でバグを追跡する最も簡単な方法は、チケットを独自のブランチに入れることでしたが、すぐにそれが良いバグを追い越すノイズでスケーリングされなかったと確信しています。

Bugzillaを見て使用しましたが、正しい「キーワード」がわからない場合は困惑することがあります。注：問題の追跡に使用された初期の時期（1991〜1995年）に特に興味があります。

「Kernel SCM saga」と「Trivia：いつgit self-host？」という2つのスレッドを見ましたが、これらはいずれも初期のカーネルのバグ追跡について言及していませんでした。

私はあちこち検索しましたが、1991年から1992年にそこにあったFOSSバグ追跡ソフトウェアを入手できませんでした。Bugzilla、Request-tracker、およびその他のユーザーはかなり遅れて登場したため、外に出ているようです。

主な質問

1. 当時、Linus、サブシステム管理者、およびユーザーはどのようにしてバグを報告および追跡しましたか？
2. 彼らはいくつかのバグ追跡ソフトウェアを使用し、バグのブランチを作成し、その中のバグに関する質問とディスカッションを手動でコミットしました（それを行うには費用がかかり、苦痛になります）。
3. その後、Bugzillaが登場し（1998年の最初のリリース）、それがその後バグを報告する主要な方法であるようです。

昔のことをより明確に把握できることを楽しみにしています。

最初に、何か貢献するもの（パッチまたはバグレポート）があれば、それをLinusにメールしました。これは、それをリスト（linux-kernel@vger.rutgers.edu以前kernel.orgに作成された）に郵送するように発展しました。

バージョン管理はありませんでした。時々、LinusはFTPサーバーにtarballを置きました。これは「タグ」に相当します。最初に利用できたツールはRCSとCVSで、Linusはそれらを嫌っていたので、誰もがパッチをメールで送信しました。（Linusから CVSを使用したくない理由について説明があります。）

Bitkeeper以前の独自のバージョン管理システムは他にもありましたが、Linuxの分散型のボランティアベースの開発により、それらを使用することは不可能になりました。バグを見つけたばかりのランダムな人は、数千ドルで始まるライセンスで独自のバージョン管理システムを通過する必要がある場合、パッチを送信しません。

Bitkeeperはこれらの問題の両方を回避しました。CVSのように集中化されておらず、フリーソフトウェアではありませんでしたが、カーネルの貢献者は無料で使用できました。それはしばらくの間それで十分でした。

今日のgitベースの開発でも、メーリングリストはまだアクションが行われている場所です。何かを貢献したいときは、もちろんgitで準備しますが、マージする前に関連するメーリングリストで議論する必要があります。Bugzillaは、「プロフェッショナル」に見え、実際には関与したくない人からの半ばバグのレポートを吸収します。

古いバグ報告の手順の一部を見るには、歴史的なLinuxリポジトリを入手してください。（これはgitが存在する前のすべてのバージョンを含むgitリポジトリです。主にtarballから再構築されたため、リリースごとに1つのコミットが含まれています）。興味のあるファイルが含まれREADME、MAINTAINERSとREPORTING-BUGS。

Linux-0.99.12のREA​​DMEには次のような興味深いものがあります。

 - if you have problems that seem to be due to kernel bugs, please mail
   them to me (Linus.Torvalds@Helsinki.FI), 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.

プロセスはニュースグループ（USENET）と（主に）電子メールを使用しました。スレッドとして「存在する」バグは、件名に「[BUG REPORT]」または「LINUX BUG REPORT」を入れるのが一般的な慣習でした。バグIDはありませんでした。典型的なユーザーベースを考えると、バグレポートにはしばしばパッチが付属していました。長い間忘れられていたソフトウェアツールが1つ使用されていました：（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

comp.os.linuxの1992年12月（0.98.6）からのバグレポートと修正を以下に示します。https ://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

非常に早い段階での電子メールのリストがあったML-linuxの-バグこのから（1993分の1992）、早期のFAQにあるSlackwareの 1.01分布：

VI.01）$＃@のようです！Linuxに移植した場合、正しく動作しません。バグを報告するにはどうすればよいですか？

[...]「ml-linux-bugs@dg-rtp.dg.com」バグ報告リストは段階的に廃止されています。Linuxには非常に少ないバグがありますが、ほとんどはバグを蓄積して投稿する前にニュースグループまたはLinusで解決されています。:)要するに、LinuxまたはLinuxに移植されたソフトウェアにバグがある場合、通常は次のパッチレベルまたはバージョンで修正されます。

「linux-kernel」メーリングリスト（元ので実行されたvger）、ニュースグループalt.os.linux、次にcomp.os.linux（1993年にすぐに階層に分割されました）がありました。

この初期のLinuxのよくある質問（V1.11 1992年11月） comp.os.linuxからも直接ライナスをメール示唆しています。

1992年、Matt Welsh（Running Linux、Linux Bible、TLDP）はibug、電子メールで送信されたバグレポートの生成を支援すると発表しました（皮肉なことに、電子メールを送信するのに十分なネットワークがなかったため、Linuxでこれを実行できませんでした）。

電子メールバグレポートテンプレートlinux.tempはcomp.os.linuxにも定期的に投稿され、バグレポートの更新にlinux.fix.tempは更新テンプレートが含まれていました。

パッチリポジトリ（FTP）もありました。これは、Linuxに移植するためのプログラムへのパッチ用であることが（ほとんどではありませんが）わかる限りです。

1993-1994

カーネルソースのCVSコピーが一般的でした。最初に見つけたのは、kernal-0.99.14時代のDirk Steinbergのものです。最初の発表私は見つけることができますは、Linux-活動家で1993年1月からです。アーカイブされたコピー（1994）を引き続き見つけることができます。Dirkは、CVSのcvsバイナリとlibcソースも維持していました。

CVSは現在の意味でバグを追跡するために使用されておらず、一部の開発者はそれを使用することを好み、パッチはcvsで生成されたdiffの形式で頻繁に提出されました。

1995-1996

この頃（1995年10月）、David S. MillerはLinuxカーネルのSPARCポート（Linux / SPARCポート）にCVSの使用を開始しました。1996年2月までに、他のいくつかのカーネル開発者が独立してCVSを使用してパッチを追跡していました。linux-kernelからこのスレッドとこのスレッド：Alan Cox、Stephen Tweedie、Kai Henningsen。（2番目のスレッドは、Russ NelsonがLinusのCVSへの直接の嫌悪を述べていると報告しています。）

1997-1998

1998年4月、Linusの2番目の子の誕生直後にCVSの問題が再び発生しました。linux -kernelからこのサブスレッドを参照してください（LinusはCVSに関する懸念を直接繰り返します）。

1997年12月に、Andrew Tridgell はウェブベースのバグトラッカーであるjitterbugをリリースしました。1998年6月までに、Alan Coxによって「linux-patches」JitterBugがlinux-kernelで提唱されていました。私が知る限り、これはLinusや他の主要開発者が使用した最初の実際のバグ追跡システムでしたが、残念ながら「linux-patches」インスタンスはオンラインではありません。

1998年9月、ビットキーパーは Larry McEvoyによってlinux-kernelで最初に宣伝されました。

1999以降

1999/2000年までに、lkml FAQは（元の）vgerのCVSツリーを参照（Q 1-16）し始めました。これは当時Andrew Tridgellによって維持されていました。

2001年12月までに、Jitterbugは支持を失いました。このlinux-kernel スレッドを参照してください。

2002年1月までに、Linusはビットキーパー（PowerPC Linuxカーネルチームで既に使用されている）に興味を持ち始めました。

2002年2月、Linusは2.5開発ツリーにBitkeeperの使用を開始しました。

2002年11月、OSDLは2.5ツリーのLinux Bugzillaをホストしました。（質問のbugzillaリンクをまだ読んでいない場合は、今すぐ読んでください。ヴィンテージLinusの暴言が含まれています）。

2005年4月にLinusが離れBitKeeperのからの移行を発表しました頃、彼は最初に述べたgit名前で。gitがセルフホスティングを行えるようになった直後、LinusはBitKeeperの使用を中止し、カーネルにgitを使用し始めました。

2008年12月、linux-kernel用のパッチワークパッチトラッカーが発表されました。これはSCCSに依存しないWebベースのパッチトラッカーであり、メーリングリストと統合してパッチとフォローアップを追跡します。その使用は今日まで継続されており、https：//patchwork.kernel.org/で約40のリストがこの方法で追跡されていますが、すべてがアクティブではありません。

参照資料

便利なリファレンス：

• 分散作業の本質：Linuxカーネルの場合（Jae Yun Moon、Lee Sproull） 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
• 重要なLinuxの投稿/メールのKenneth R. Saborioのアーカイブ：http : //www.informatica.co.cr/linux/index.htm（1991-2005）
• 今日（2014年11月）、バックからのLinuxカーネルのアーカイブ1995 http://lkml.iu.edu/hypermail/linux/kernel/ （悲しいことに、最初のメールは、管理者クリス・デントは、彼が以前を失った発表1995年6月からですアーカイブ...） LKMLアーカイブは1996年にのみ遡ります
• tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux-の 1993-1994年のlinux-develのフラグメント devel / （URLおよびファイルの日付を無視します）
• バージョン管理ツール：LinuxカーネルでのCVSからBKへ、Sjaikh＆Cornford（約2003年）
• gitの10周年が近づくにつれて、このHacker Newsスレッド（2015年3月）も参照してください：https : //news.ycombinator.com/item?id=9263336

バグ報告がgitそれ自体の開発のためにどのように処理されるかを知ることができます。

バグ追跡ソフトウェアは使用しません。バグは開発メーリングリストで報告および議論されています。それはおそらく驚くべきことですが、非常にうまく機能します。

バグ追跡ソフトウェアを使用するという質問や提案が頻繁に出てくるので、gitメーリングリストアーカイブを検索することでこれについて多くを学ぶことができます。

「十分なバグトラッカーがまだ見つかりませんでした」ということではありません。
しかし、それは「優れた方法がある」ということでもありません。

この方法では、プロジェクトまたはサブプロジェクトのメンテナー（開発主任のようなもの）が開発リストの非公式のモデレーターとして重要な役割を果たします。
バグの処理はその一部であり、この方法でバグを管理することは簡単な作業ではないようです。それは確かにその役割の人のスキルに依存します。

メソッドの最も正式な部分は、毎週のステータスサマリーメッセージです。
さまざまなブランチで現在行われていることを短い項目としてリストします。git開発の例についてはgmane.comp.version-control.git、メーリングリストをミラーリングするニュースグループでこれを参照してください：git.gitで料理しているもの

確かに言えること：これが得意なメンテナーがいれば、非常にうまく機能します。
たとえば、バグトラッカーの導入により、変更のオーバーヘッドを償却した後でも、実装された機能と品質に生産性がプラスの影響を与えた場合、私は非常に驚きます。

Linuxカーネルの場合は、今日までのgitの場合と同様です。
Linuxカーネル開発の開発メーリングリストは確かに重要です。しかし、gitのように中心的な場所としての1つのリストではありません。ファイルシステムやネットワークなど、サブトピック用の個別のリストがあります。
ほとんどの場合別々の開発者によって処理される別個のトピックがあるため、一部のグループはグループに対してローカルでツールを使用する可能性があります。