Pada awalnya, jika Anda memiliki sesuatu untuk disumbangkan (tambalan atau laporan bug), Anda mengirimkannya ke Linus. Ini berkembang menjadi mengirimkannya ke daftar (yaitu [email protected] sebelum kernel.org telah dibuat).
Tidak ada kontrol versi. Dari waktu ke waktu, Linus memasang tarball di server FTP. Ini setara dengan "tag". Alat yang tersedia pada awalnya adalah RCS dan CVS, dan Linus membencinya, jadi semua orang hanya mengirimkan tambalan. (Ada penjelasan dari Linus kenapa dia tidak mau menggunakan CVS.)
Ada sistem kontrol versi pra-Bitkeeper lainnya, tetapi pengembangan Linux berbasis sukarelawan yang terdesentralisasi membuat 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 tersebut:tidak terpusat seperti CVS, dan meskipun bukan Perangkat Lunak Bebas, kontributor kernel diizinkan untuk menggunakannya tanpa membayar. Itu membuatnya cukup baik untuk sementara waktu.
Bahkan dengan pengembangan berbasis git saat ini, milis masih menjadi tempat aksinya. Ketika Anda ingin menyumbangkan sesuatu, Anda akan mempersiapkannya dengan git tentu saja, 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 benar-benar ingin terlibat.
Untuk melihat beberapa petunjuk pelaporan bug 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 tarbal). File yang menarik termasuk README , MAINTAINERS , dan REPORTING-BUGS .
Salah satu hal menarik yang dapat Anda temukan di sini 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 "ada" sebagai utas, menempatkan "[BUG REPORT] " atau "LINUX BUG REPORT " dalam subjek adalah konvensi umum. Tidak ada ID bug. Mengingat basis pengguna yang khas, laporan bug sering datang dengan tambalan. Ada satu alat perangkat lunak yang sudah lama terlupakan digunakan:ibug (lihat di bawah), selain diff itu +patch .
Dari Instalasi Linux dan Memulai (Jan 1994, salinan arsip 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
Berikut 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-bugs (1992/1993), dari FAQ awal ini di distribusi Slackware 1.01:
VI.01) Sepertinya $#@! porting di linux tidak berjalan dengan benar, apa yang harus saya lakukan untuk melaporkan bug?
[...]Perhatikan bahwa daftar pelaporan bug "[email protected]" saya telah dihapus. Ternyata Linux memiliki begitu sedikit bug, sebagian besar diselesaikan di newsgroup atau melalui Linus sebelum saya dapat mengumpulkannya dan mempostingnya. :) Singkatnya:jika ada bug di Linux atau di Linux-portedsoftware, biasanya akan diperbaiki di patchlevel atau versi berikutnya.
Ada daftar email "linux-kernel" (yang berjalan pada vger asli ), newsgroup alt.os.linux, lalu comp.os.linux (yang dengan cepat terbagi menjadi hierarki pada tahun 1993).
FAQ Linux awal ini (v1.11 Nov 1992) dari comp.os.linux juga menyarankan untuk mengirim email ke Linus secara langsung.
Pada tahun 1992 Matt Welsh (Menjalankan Linux , Alkitab Linux , TLDP) mengumumkan ibug untuk membantu membuat laporan bug yang dikirim melalui email (ironisnya, Anda tidak dapat menjalankan ini di Linux pada saat itu karena tidak memiliki jaringan yang memadai untuk dapat mengirim email).
Templat laporan bug email linux.temp juga diposting secara berkala di comp.os.linux, dan pembaruan laporan bug memiliki templat pembaruan linux.fix.temp .
Ada juga repositori tambalan (FTP), sejauh yang saya tahu ini sebagian besar (tidak eksklusif) untuk tambalan ke program untuk porting ke Linux.
1993-1994
Salinan CVS dari sumber kernel adalah umum, yang paling awal saya temukan adalah Dirk Steinberg's, dari era kernal-0.99.14. Pengumuman pertama yang dapat saya temukan adalah dari Jan 1993 di linux-activists. Anda masih dapat menemukan salinan arsip (1994). Dirk juga mempertahankan biner cvs dan sumber libc di CVS.
CVS tidak digunakan untuk melacak bug dalam pengertian kontemporer, beberapa developer lebih suka menggunakannya, dan tambalan sering dikirimkan dalam bentuk perbedaan yang dihasilkan cvs.
1995-1996
Sekitar waktu ini (Okt 1995) David S. Miller mulai menggunakan CVS untuk port SPARC dari kernel Linux (Port Linux/SPARC ). Pada Februari 1996 beberapa pengembang kernel lain secara independen menggunakan CVS untuk melacak tambalan, dari linux-kernel utas ini dan utas ini:Alan Cox, Stephen Tweedie, Kai Henningsen. (Utas kedua melaporkan Russ Nelson menyatakan secara langsung keengganan Linus terhadap CVS.)
1997-1998
Pada bulan April 1998, tak lama setelah kelahiran anak kedua Linus, masalah CVS muncul lagi, dari linux-kernel lihat subthread ini (Linus menegaskan kembali kekhawatirannya tentang CVS di sana secara langsung).
Pada Desember 1997, Andrew Tridgell merilis jitterbug, pelacak bug berbasis web. Pada bulan Juni 1998, JitterBug "linux-patches" diadvokasi di linux-kernel oleh Alan Cox. Ini sejauh yang saya tahu, sistem pelacakan bug aktual pertama yang digunakan oleh Linus dan pengembang utama lainnya, sayangnya contoh "linux-patches" tidak lagi online.
Pada bulan September 1998, bitkeeper pertama kali dipromosikan di linux-kernel oleh Larry McEvoy.
1999 dan sesudahnya
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 lagi disukai, lihat utas kernel linux ini, Linus, Alan Cox, dan banyak lainnya terlibat dalam diskusi alasannya.
Pada Jan 2002, Linus mulai tertarik dengan bitkeeper (sudah digunakan oleh tim kernel PowerPC Linux).
Pada Februari 2002 Linus mulai menggunakan Bitkeeper untuk pohon pengembangan 2.5.
Pada November 2002, OSDL menghosting Linux Bugzilla untuk pohon 2.5 diumumkan. (Jika Anda belum membaca tautan bugzilla dalam pertanyaan, buka dan baca sekarang, ini berisi kata-kata kasar Linus kuno).
Pada bulan April 2005 Linus mengumumkan pindah dari BitKeeper, sekitar waktu dia pertama kali menyebutkan git dengan nama. Tak lama setelah git mampu menghosting sendiri, Linus berhenti menggunakan BitKeeper dan mulai menggunakan git untuk kernel.
Pada bulan Desember 2008, pelacak tambalan tambal sulam untuk kernel linux 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 semuanya aktif.
Referensi
Referensi yang berguna:
- Esensi pekerjaan terdistribusi:Kasus kernel Linux (Jae Yun Moon, Lee Sproull)http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (Nov 2000)
- Panduan pelaporan 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)
- Linux-kernel arsip dari hari ini (Nov 2014) kembali ke 1995http://lkml.iu.edu/hypermail/linux/kernel/(sayangnya, email pertama dari Juni 1995 di mana administrator Chris Dent mengumumkan dia telah kehilangan arsip sebelumnya ...)arsip LKML hanya kembali ke tahun 1996
- Fragmen dari linux-devel 1993-1994 dari tsx11http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/ linux-devel/(abaikan tanggal di URL dan di file)
- Alat Manajemen Versi:CVS ke BK di Kernel Linux , Sjaikh &Cornford (ca. 2003)
- Lihat juga Berita Peretas ini thread (Maret 2015) menjelang peringatan 10 tahun git:https://news.ycombinator.com/item?id=9263336
Saya tahu bagaimana pelaporan bug ditangani untuk pengembangan git itu sendiri.
Mereka tidak menggunakan perangkat lunak pelacakan bug apa pun. Bug dilaporkan dan didiskusikan di milis pengembangan. Ini mungkin mengejutkan, tetapi bekerja dengan sangat baik.
Pertanyaan atau usulan untuk menggunakan beberapa perangkat lunak pelacakan bug sering muncul, jadi Anda dapat mempelajari banyak hal tentang ini dari menelusuri arsip milis git.
Ini bukan tentang "kami belum menemukan pelacak bug yang cukup bagus";
Namun ini juga bukan tentang "kami memiliki metode yang unggul".
Dengan metode ini, pengelola proyek atau sub proyek - seperti pengembang utama - memiliki peran penting sebagai moderator informal dari daftar pengembangan.
Menangani bug adalah bagian darinya, dan sepertinya bukan tugas yang 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 mencantumkan hal-hal yang sedang terjadi di berbagai cabang sebagai item pendek. Sebagai contoh dari pengembangan git, lihat ini di newsgroup gmane.comp.version-control.git mencerminkan milis:Apa yang sedang dimasak di git.git
Apa yang bisa saya katakan dengan pasti:Jika Anda memiliki pengelola yang ahli dalam hal ini, ini bekerja dengan sangat baik.
Misalnya, saya akan sangat terkejut jika pengenalan pelacak bug berdampak positif pada produktivitas pada fitur dan kualitas yang diimplementasikan, bahkan dalam jangka panjang setelah amortisasi overhead perubahan.
Untuk kernel Linux, 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 git. Ada daftar terpisah untuk subtopik, seperti sistem file, atau jaringan.
Karena ada topik terpisah, yang ditangani oleh sebagian besar developer terpisah, beberapa grup mungkin menggunakan alat secara lokal untuk grup mereka.