Bagaimana proyek Kernel Linux melacak bug di Masa Dini?

Kita semua tahu bahwa Linus Torvalds menciptakan Git karena masalah dengan Bitkeeper. Apa yang tidak diketahui (setidaknya bagi saya) adalah, bagaimana masalah / tiket / bug dilacak sampai saat itu? Saya mencoba tetapi tidak mendapatkan sesuatu yang menarik. Satu-satunya diskusi yang saya dapat membahas tentang hal ini adalah diskusi di mana Linus berbagi keprihatinan dengan penggunaan Bugzilla .

Spekulasi: - Cara termudah bagi orang untuk melacak bug pada tahap awal adalah dengan meletakkan tiket di cabang sendiri, tetapi saya yakin itu cukup cepat yang tidak akan diskalakan dengan kebisingan karena mengambil alih bug yang baik.

Saya telah melihat dan menggunakan Bugzilla dan kecuali Anda tahu kata kunci yang tepat di kali Anda akan bingung. CATATAN: Saya secara khusus tertarik pada tahun-tahun awal (1991-1995) tentang bagaimana mereka digunakan untuk melacak masalah.

Saya memang melihat dua utas, " Kernel SCM saga ", dan " Trivia: Kapan git self-host? " Tetapi tidak ada yang menyebutkan tentang pelacakan bug pada kernel di awal-awal.

Saya mencari-cari dan tidak bisa mendapatkan perangkat lunak pelacakan bug FOSS yang ada di sana pada 1991-1992. Bugzilla, Request-tracker, dan yang lainnya datang jauh kemudian, sehingga mereka tampak keluar.

Pertanyaan kunci

1. Bagaimana Linus, pengelola subsistem, dan pengguna melaporkan dan melacak bug pada masa itu?
2. Apakah mereka menggunakan beberapa perangkat lunak pelacakan bug, membuat cabang bug dan secara manual melakukan pertanyaan dan diskusi tentang bug di dalamnya (akan mahal dan menyakitkan untuk melakukan itu) atau hanya menggunakan email.
3. Banyak kemudian, Bugzilla datang (rilis pertama 1998) dan itu tampaknya menjadi cara utama untuk melaporkan bug setelahnya .

Berharap untuk memiliki gambaran yang lebih jelas tentang bagaimana hal-hal dilakukan di masa lalu.

Pada awalnya, jika Anda memiliki sesuatu untuk disumbangkan (tambalan atau laporan bug), Anda mengirimkannya ke Linus. Ini berkembang menjadi mengirimkannya ke daftar (yang [email protected]sebelumnya kernel.orgdibuat).

Tidak ada kontrol versi. Dari waktu ke waktu, Linus menaruh tarball di server FTP. Ini setara dengan "tag". Alat yang tersedia pada awalnya adalah RCS dan CVS, dan Linus membenci itu, jadi semua orang hanya mengirimkan tambalan. (Ada penjelasan dari Linus tentang mengapa dia tidak ingin menggunakan CVS.)

Ada sistem kontrol versi berpemilik pra-Bitkeeper lainnya, tetapi pengembangan Linux berbasis sukarela yang didesentralisasi membuatnya tidak mungkin untuk menggunakannya. Orang acak yang baru saja menemukan bug tidak akan pernah mengirim tambalan jika harus melalui sistem kontrol versi berpemilik dengan lisensi mulai dari ribuan dolar.

Bitkeeper mengatasi kedua masalah itu: itu tidak terpusat seperti CVS, dan sementara itu bukan Perangkat Lunak Bebas, kontributor kernel diizinkan untuk menggunakannya tanpa membayar. Itu membuatnya cukup baik untuk sementara waktu.

Bahkan dengan perkembangan berbasis git saat ini, mailing list masih menjadi tempat aksi. Ketika Anda ingin menyumbangkan sesuatu, Anda tentu akan menyiapkannya dengan git, tetapi Anda harus mendiskusikannya di milis yang relevan sebelum digabungkan. Bugzilla hadir untuk terlihat "profesional" dan menyerap laporan bug setengah matang dari orang-orang yang tidak benar - benar ingin terlibat.

Untuk melihat beberapa instruksi pelaporan bug yang lama, dapatkan repositori Linux historis . (Ini adalah repositori git yang berisi semua versi dari sebelum git ada; sebagian besar berisi satu komit per rilis sejak direkonstruksi dari tarballs). File yang menarik termasuk README, MAINTAINERS, dan REPORTING-BUGS.

Salah satu hal menarik yang dapat Anda temukan di sana adalah dari Linux-0.99.12 README:

 - 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.

Prosesnya menggunakan grup berita (USENET), dan (terutama) email. Bug yang "ada" sebagai utas, menempatkan " [BUG REPORT]" atau " LINUX BUG REPORT" pada subjek adalah kebiasaan umum. Tidak ada ID bug. Mengingat basis pengguna yang khas, laporan bug sering kali disertai dengan tambalan. Ada satu alat perangkat lunak yang sudah lama terlupakan digunakan: ibug(lihat di bawah), selain itu diff+ patch.

Dari Instalasi Linux dan Memulai (Jan 1994, v2.0 menyalin arsip) >

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

Berikut ini adalah laporan bug dan perbaikan dari Desember 1992 (0.98.6) di comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Sangat awal ada daftar email ml-linux-bug (1992/1993), dari FAQ awal ini di distribusi Slackware 1.01:

VI.01) Tampaknya $ # @! porting di linux tidak berjalan dengan benar, apa yang harus saya lakukan untuk melaporkan bug?

[...] Perhatikan bahwa daftar pelaporan bug "[email protected]" saya sudah dihapus. Ternyata Linux memiliki sedikit sekali bug, yang sebagian besar diselesaikan pada newsgroup atau melalui Linus sebelum saya dapat mengakumulasikannya dan mempostingnya. :) Singkatnya: jika ada bug di Linux atau di perangkat lunak Linux porting, biasanya akan diperbaiki di patchlevel atau versi berikutnya.

Ada daftar email "linux-kernel" (yang berjalan pada yang asli vger), newsgroup alt.os.linux, kemudian comp.os.linux (yang dengan cepat terpecah menjadi hierarki pada tahun 1993 ).

FAQ Linux awal ini (v1.11 Nov 1992) dari comp.os.linux juga menyarankan untuk mengirim email langsung ke Linus.

Pada tahun 1992 Matt Welsh ( Menjalankan Linux , Linux Bible , TLDP ) mengumumkanibug untuk membantu dalam menghasilkan laporan bug yang diemail (ironisnya, Anda tidak dapat menjalankan ini di Linux pada waktu itu karena tidak memiliki jaringan yang cukup untuk dapat mengirim email).

Templat laporan kutulinux.temp email juga secara berkala diposting di comp.os.linux, dan pembaruan pada laporan kutu memiliki templat pembaruanlinux.fix.temp .

Ada juga repositori patch (FTP) , sejauh yang saya tahu ini sebagian besar (tidak eksklusif) untuk patch ke program untuk porting ke Linux.

1993-1994

Salinan CVS dari sumber kernel adalah umum, yang paling awal saya temukan adalah Dirk Steinberg, dari era kernal-0.99.14. The pengumuman pertama saya dapat menemukan adalah dari tahun 1993 Jan di linux-aktivis. Anda masih dapat menemukan salinan yang diarsipkan (1994) . Dirk juga memelihara cvs binari dan sumber libc di CVS.

CVS tidak digunakan untuk melacak bug dalam pengertian kontemporer, beberapa pengembang lebih suka menggunakannya, dan patch sering dikirimkan dalam bentuk cv yang dihasilkan oleh diff.

1995-1996

Sekitar waktu ini (Oktober 1995) David S. Miller mulai menggunakan CVS untuk port SPARC dari kernel Linux ( The Linux / SPARC port ). Pada Februari 1996, beberapa pengembang kernel lain secara independen menggunakan CVS untuk melacak patch, dari linux-kernel utas ini dan utas ini : Alan Cox, Stephen Tweedie, Kai Henningsen. (Utas kedua melaporkan Russ Nelson menyatakan keengganan Linus untuk CVS.)

1997-1998

Pada April 1998, tak lama setelah kelahiran anak kedua Linus, masalah CVS muncul lagi, dari linux-kernel lihat subthread ini (Linus menegaskan kembali keprihatinannya tentang CVS di sana secara langsung).

Pada Desember 1997, Andrew Tridgell merilis jitterbug , pelacak bug berbasis web. Pada Juni 1998, "linux-patches" JitterBug diadvokasi di linux-kernel oleh Alan Cox . Sejauh yang saya tahu, sistem pelacakan bug pertama yang digunakan oleh Linus dan pengembang kunci lainnya, sayangnya contoh "linux-patches" tidak lagi online.

Pada bulan September 1998, bitkeeper pertama kali dipromosikan di linux-kernel oleh Larry McEvoy.

1999 dan kemudian

Pada 1999/2000, FAQ lkml mulai merujuk (Q 1-16) ke pohon CVS di vger (asli). Ini dipertahankan pada saat itu oleh Andrew Tridgell.

Pada Desember 2001, Jitterbug tidak disukai lagi, lihat thread linux-kernel ini , Linus, Alan Cox dan banyak lainnya terlibat dalam diskusi mengapa.

Pada Januari 2002, Linus mulai tertarik pada bitkeeper (sudah digunakan oleh tim kernel PowerPC Linux).

Pada Februari 2002, Linus mulai menggunakan Bitkeeper untuk pohon pengembangan 2.5.

Pada November 2002 OSDL menjadi tuan rumah Linux Bugzilla untuk pohon 2.5 diumumkan . (Jika Anda belum membaca tautan bugzilla dalam pertanyaan, buka dan baca sekarang, ini berisi kata-kata Linus vintage).

Pada bulan April 2005 Linus mengumumkan pindah dari BitKeeper , sekitar waktu ia pertama kali disebutkan gitnamanya . Tak lama setelah git menjadi self-hosting , Linus berhenti menggunakan BitKeeper dan mulai menggunakan git untuk kernel.

Pada bulan Desember 2008 pelacak tambal sulam Patchwork untuk linux-kernel diumumkan , ini adalah pelacak tambalan berbasis web SCCS-agnostik yang terintegrasi dengan milis untuk melacak tambalan dan tindak lanjut. Penggunaannya berlanjut hingga hari ini, ada sekitar 40 daftar yang dilacak dengan cara ini di https://patchwork.kernel.org/ , meskipun tidak semua aktif.

Referensi

Referensi yang berguna:

• Inti dari pekerjaan terdistribusi: Kasus kernel Linux (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (Nov 2000)
• Pedoman untuk melaporkan bug Linux (Jul 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Arsip Kenneth R. Saborio tentang postingan / email penting Linux: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• arsip linux-kernel mulai hari ini (November 2014) kembali ke 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (sayangnya, email pertama adalah dari Juni 1995 di mana administrator Chris Dent mengumumkan dia telah kehilangan yang sebelumnya arsip ...) Arsip LKML hanya kembali ke tahun 1996
• Fragmen dari linux-devel 1993-1994 dari tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (abaikan tanggal di URL dan pada file)
• Alat Manajemen Versi: CVS ke BK di Linux Kernel , Sjaikh & Cornford (ca. 2003)
• Lihat juga utas Peretas Berita ini (Maret 2015) sebagai peringatan 10 tahun pendekatan git: https://news.ycombinator.com/item?id=9263336

Saya bisa tahu bagaimana pelaporan bug ditangani untuk pengembangan gititu sendiri.

Mereka tidak menggunakan perangkat lunak pelacakan bug. Bug dilaporkan dan didiskusikan di milis pengembangan . Ini mungkin mengejutkan, tetapi bekerja dengan sangat baik.

Pertanyaan atau proposal untuk menggunakan beberapa perangkat lunak pelacakan bug sering muncul, sehingga Anda dapat belajar banyak tentang ini dari mencari arsip milis git.

Ini bukan tentang "kami belum menemukan pelacak bug yang cukup baik";
Tetapi ini juga bukan tentang "kita memiliki metode yang unggul".

Dengan metode ini, pemelihara proyek atau sub-proyek - sesuatu seperti pengembang utama - memiliki peran penting sebagai moderator informal dari daftar pengembangan.
Menangani bug adalah bagian darinya, dan sepertinya bukan tugas sepele untuk mengelola bug dengan cara ini; Itu tentu tergantung pada keterampilan orang dalam peran itu.

Bagian paling formal dari metode ini adalah pesan ringkasan status mingguan.
Ini daftar hal-hal yang saat ini terjadi di berbagai cabang sebagai item pendek. Untuk contoh dari pengembangan git, lihat ini di newsgroup yang gmane.comp.version-control.gitmencerminkan milis: Apa yang sedang dimasak di git.git

Apa yang bisa saya katakan dengan pasti: Jika Anda memiliki pengelola yang ahli dalam hal ini, itu bekerja dengan sangat baik.
Sebagai contoh, saya akan sangat terkejut jika pengenalan pelacak bug memiliki efek positif produktivitas pada fitur dan kualitas yang diimplementasikan, bahkan dalam jangka panjang setelah amortisasi overhead perubahan.

Untuk kernel Linux, ini mirip seperti yang dilakukan untuk git, hingga saat ini.
Milis pengembangan untuk pengembangan kernel Linux tentu saja penting. Tapi itu bukan satu daftar sebagai tempat sentral seperti dengan git. Ada daftar terpisah untuk subtopik, seperti sistem file, atau jaringan.
Karena ada topik terpisah, sebagian besar ditangani oleh pengembang yang terpisah, ada kemungkinan beberapa kelompok menggunakan alat secara lokal untuk grup mereka.