最初は、貢献したいもの (パッチやバグレポート) があれば、それを Linus にメールで送りました。これはリストへのメール送信に発展しました (これは [email protected] でした) kernel.org より前 が作成されました)。
バージョン管理はありませんでした。ときどき、Linus は FTP サーバーに tarball を置きました。これは「タグ」に相当します。最初に利用可能なツールは RCS と CVS でしたが、Linus はそれらが嫌いだったので、誰もがパッチを郵送するだけでした。 (CVS を使いたくなかった理由について、Linus からの説明があります。)
他にも 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.
このプロセスでは、ニュース グループ (USENET) と (主に) 電子メールを使用しました。バグがスレッドとして「存在」し、「[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
comp.os.linux の 1992 年 12 月 (0.98.6) のバグ レポートと修正は次のとおりです:https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion
非常に早い段階で、ml-linux-bugs というメーリング リストがありました。 (1992/1993)、Slackware 1.01 ディストリビューションのこの初期の FAQ から:
<ブロック引用>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 Nov 1992) も、Linus に直接電子メールを送ることを提案しています。
1992 年、Matt Welsh (Running Linux) 、Linux 聖書 、TLDP) が ibug を発表しました 電子メールで送信されるバグ レポートの生成を支援します (皮肉なことに、電子メールを送信できる十分なネットワークがなかったため、当時はこれを Linux で実行できませんでした)。
電子メール バグ レポート テンプレート linux.temp comp.os.linux にも定期的に投稿され、バグレポートの更新には更新テンプレート linux.fix.temp がありました .
パッチ リポジトリ (FTP) もありましたが、私が知る限り、これはほとんど (排他的ではありません) Linux への移植用プログラムへのパッチ用でした。
1993-1994
カーネル ソースの CVS コピーは一般的でした。私が見つけた最も古いものは、kernal-0.99.14 時代の Dirk Steinberg のものです。私が見つけた最初の発表は、1993 年 1 月の linux-activists に関するものです。アーカイブされたコピー (1994 年) を見つけることができます。 Dirk はまた、CVS で cvs バイナリと libc ソースを維持しました。
CVS は、現代的な意味でのバグ追跡には使用されませんでした。一部の開発者は CVS を好んで使用し、パッチは cvs によって生成された差分の形式で頻繁に送信されました。
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 は、Web ベースのバグ トラッカーであるitterbug をリリースしました。 1998 年 6 月までに、「linux-patches」JitterBug が Alan Cox によって linux-kernel で提唱されていました。私が知る限り、これは Linus やその他の主要な開発者が実際に使用した最初のバグ追跡システムでした。残念ながら、「linux-patches」インスタンスはオンラインではなくなりました。
1998 年 9 月、bitkeeper は Larry McEvoy によって linux-kernel で最初に昇格されました。
1999年以降
1999/2000 年までに、lkml FAQ は (元の) vger の CVS ツリーに言及し始めました (Q 1-16)。これは当時、Andrew Tridgell によって維持されていました。
2001 年 12 月までに、Jitterbug は人気を失いました。この linux-kernel スレッドを参照してください。Linus、Alan Cox、および他の多くの人が理由の議論に参加しています。
2002 年 1 月までに、Linus は bitkeeper に興味を持ち始めました (既に PowerPC Linux カーネル チームで使用されています)。
2002 年 2 月、Linus は 2.5 開発ツリーに Bitkeeper を使い始めました。
2002 年 11 月、2.5 ツリー用の OSDL ホスト Linux Bugzilla が発表されました。 (質問のバグジラのリンクをまだ読んでいない場合は、今すぐ読んでください。Linus の昔の暴言が含まれています)。
2005 年 4 月、Linus は BitKeeper から離れることを発表しました。その頃、彼は最初に git について言及しました。 名前で。 git が自己ホストできるようになった直後、Linus は BitKeeper の使用をやめ、カーネルに git を使い始めました。
2008 年 12 月、linux-kernel 用の Patchwork パッチ トラッカーが発表されました。これは、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
- Kenneth R. Saborio の重要な Linux 投稿/電子メールのアーカイブ:http://www.informatica.co.cr/linux/index.htm (1991-2005)
- 今日 (2014 年 11 月) から 1995 年までさかのぼる linux-kernel のアーカイブ http://lkml.iu.edu/hypermail/linux/kernel/ (残念ながら、最初の電子メールは 1995 年 6 月のもので、管理者の Chris Dent が紛失を発表したものです。以前のアーカイブ ...)LKML アーカイブは 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 (2003年頃)
- このハッカー ニュースも参照してください git の 10 周年が近づくスレッド (2015 年 3 月):https://news.ycombinator.com/item?id=9263336
git の開発でバグ報告がどのように処理されているかがわかります
バグ追跡ソフトウェアは使用していません。バグは開発メーリングリストで報告され、議論されています。驚くかもしれませんが、非常にうまく機能します。
バグ追跡ソフトウェアを使用するという質問や提案が頻繁に出てくるので、git メーリング リストのアーカイブを検索すると、これについて多くのことを学ぶことができます。
「十分なバグトラッカーがまだ見つかっていない」ということではありません。
しかし、「優れた方法がある」ということでもありません。
この方法では、プロジェクトまたはサブプロジェクトのメンテナー (主任開発者のようなもの) が、開発リストの非公式のモデレーターとして重要な役割を果たします。
バグの処理はその一部であり、この方法でバグを管理するのは簡単な作業ではないようです。それは確かに、その役割を担う人のスキルに依存します.
メソッドの最も正式な部分は、毎週のステータス サマリー メッセージです。
さまざまなブランチで現在進行中のことを短い項目としてリストします。 git 開発の例については、ニュースグループ gmane.comp.version-control.git でこれを参照してください。 メーリング リストのミラーリング:git.git の調理法
私が確実に言えることは、これが得意なメンテナーがいる場合、非常にうまく機能するということです。
たとえば、私はとても バグトラッカーの導入が、変更のオーバーヘッドを償却した後でも、実装された機能と品質の生産性にプラスの効果をもたらしたことに驚きました.
Linux カーネルの場合、現在までの git の場合と同様です。
Linux カーネル開発の開発メーリング リストは確かに重要です。しかし、git のように中心的な場所としての 1 つのリストではありません。ファイルシステムやネットワーキングなどのサブトピックには別のリストがあります。
別々のトピックがあり、ほとんど別々の開発者によって処理されているため、一部のグループがそのグループに対してローカルでツールを使用している可能性があります。