web-dev-qa-db-ja.com

Linuxカーネルプロジェクトは、初期の段階でバグをどのように追跡しましたか？

Linkeeper TorvaldsがGitを作成したのは、Bitkeeperの問題が原因だったのは誰でも知っています。 （少なくとも私にとって）知られていないのは、それまでに問題/チケット/バグがどのように追跡されたのですか？試しましたが何も面白くありませんでした。私がこの問題について話し合うことができた唯一の議論は、 LinusがBugzilla の使用に関する懸念を共有したこの議論でした。

スペキュレーション：-初期段階でバグを追跡する最も簡単な方法は、チケットを独自のブランチに置くことでしたが、そのことは確かです。すぐにそれは、良いバグを追い越すノイズでスケーリングしなかったでしょう。

私はBugzillaを見て使用しましたが、適切な「キーワード」を知らなければ、困惑することでしょう。 注：私は特にそれらの方法問題の追跡に使用。

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

私は周りを検索しましたが、1991〜1992年に存在していたFOSSバグ追跡ソフトウェアを入手することができませんでした。 Bugzilla、Request-tracker、その他はかなり遅れて登場したため、それらはリリースされたようです。

主な質問

  1. では、Linus、サブシステムの保守担当者、およびユーザーは、当時のバグをどのように報告および追跡したのでしょうか。
  2. 彼らはいくつかのバグ追跡ソフトウェアを使用したり、バグの分岐を作成したり、そこにあるバグについて手動でコミットした質問やディスカッションを行ったり（コストがかかり、それを行うのは面倒）、電子メールを使用したりしました。
  3. ずっと後に、Bugzillaが登場しました（最初のリリース1998）。それは、後でバグを報告する 主な方法のようです 。

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

linuxkernelgithistory
29
shirish

最初は、貢献するものがあれば（パッチまたはバグレポート）、それをLinusにメールしました。これは、リストにメールで送信するように進化しました（[email protected]が作成される前はkernel.orgでした）。

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

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

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

今日のgitベースの開発でさえ、メーリングリストはまだ行動の場所です。何かを寄付したい場合は、もちろんgitで準備しますが、マージする前に関連するメーリングリストで議論する必要があります。 Bugzillaは、「プロフェッショナル」のように見え、関与したくない本当に人々からの半熟なバグレポートを吸収します。

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

Linux-0.99.12のREA​​DMEにある興味深いものの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.
20
user41515

プロセスはニュースグループ（USENET）と（主に）メールを使用しました。件名に「_[BUG REPORT]_」または「_LINUX BUG REPORT_」を入れて、スレッドとして「存在」するバグは一般的な慣例でした。バグIDはありませんでした。典型的なユーザーベースを考えると、バグレポートにはしばしばパッチが付属しています。長い間忘れられていた1つのソフトウェアツール、ibug + diff以外のpatch（下記を参照）が使用されました。

From Linux Installation and Getting Started（Jan 1994、v2.0 archived copy） >

_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-bugs（1992/1993）がありました 初期FAQSlackware 1.01ディストリビューション：

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

[...]「[email protected]」バグ報告リストは段階的に廃止されました。 Linuxにはバグがほとんどないことがわかりました。バグの多くは、ニュースグループまたはLinusで解決してから、私がそれらを蓄積して投稿します。 :)要するに、LinuxまたはLinuxに移植されたソフトウェアにバグがある場合、通常は次のパッチレベルまたはバージョンで修正されます。

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

これは、comp.os.linuxからの 初期Linux FAQ（v1.11 1992年11月） でも、Linusに直接メールを送ることをお勧めしています。

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

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

Linuxに移植するためのプログラムへのパッチのほとんど（排他的ではない）であると私が知る限り、 パッチリポジトリ（FTP） もありました。

1993-1994

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

CVSは現代的な意味でのバグの追跡には使用されず、一部の開発者はそれを使用することを好み、パッチはcvsが生成した差分の形式で頻繁に送信されました。

1995-1996

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

1997-1998

1998年4月、Linusの2番目の子供の誕生の直後に、linux-kernelから this subthread を参照して、CVSの問題が再び浮上しました（Linusは、CVSに関する懸念を直接繰り返し述べています）。

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

1998年9月、 ビットキーパーはlinux-kernelで最初にプロモートされます はLarry McEvoyです。

1999以降

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

2001年12月までに、Jitterbugは好意を失いました。このlinux-kernel thread を参照してください。Linus、Alan Coxや他の多くの人々がその理由の議論に参加しています。

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

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

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

2005年4月 LinusはBitKeeperからの離脱を発表した 、その頃 彼は最初にgitを名前で述べた だ。 gitがセルフホスティング可能になった の直後に、LinusはBitKeeperの使用をやめ、カーネルにgitの使用を開始しました。

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

参考文献

役立つリファレンス：

15
mr.spuratic

git自体の開発でバグレポートがどのように処理されるかがわかります。

彼らはバグ追跡ソフトウェアを使用していません。バグは 開発メーリングリスト で報告され、議論されます。驚くかもしれませんが、非常にうまく機能します。

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

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

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

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

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


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

4
Volker Siegel