Mengapa beberapa proyek besar, seperti Git dan Debian, hanya menggunakan milis dan bukan pelacak masalah?


65

Pelacak bug untuk setiap proyek berukuran layak tampak seperti sedikit tidak masuk akal bagi saya - itu membuatnya sangat mudah untuk mengatur ratusan atau ribuan masalah, tanpa masalah bertabrakan atau terlibat.

Jadi ketika saya melihat beberapa proyek yang sangat besar, seperti Git, menggunakan mailing list sebagai metode utama dalam mengoordinasikan pemeliharaan dan pengembangan, saya agak terkejut. Contoh:

  • Git - Halaman komunitas :

    ... Laporan bug harus dikirim ke milis ini.

  • Sistem pelacakan bug Debian , per Wikipedia:

    ... Fitur uniknya adalah tidak memiliki bentuk antarmuka web apa pun untuk mengedit laporan bug - semua modifikasi dilakukan melalui email.

Banyak pelacak bug modern memiliki integrasi yang sangat baik dengan email (Anda dapat menerima komentar atau pemberitahuan tentang bug yang Anda tonton, atau yang ditugaskan kepada Anda), serta sistem kontrol versi (komit dapat ditandai sebagai penyelesaian masalah, dll. .). Sebagian besar dari ini harus dilakukan secara manual dengan milis, dan Anda mendapatkan banyak email tentang bug yang tidak Anda minati.

Jadi apa keuntungan utama dari mailing list dibandingkan pelacak bug berbasis web? Mengapa beberapa proyek besar hanya menggunakan milis?


2
Ya, tidak, saya setuju dengan Anda, Git menggunakan milis :) Apa yang saya katakan adalah bahwa Anda menyamakannya dengan "beberapa proyek yang sangat besar" dan saya hanya berpikir bahwa jika Anda melakukannya Anda harus memberikan sedikit lebih banyak contoh untuk proyek-proyek yang sangat besar. Kalau tidak, pertanyaannya adalah "Git menggunakan milis, mengapa begitu?" dalam hal ini jawaban Jörg W Mittag lebih cocok ...
Shivan Dragon

1
Hrm, yah saya mendapat kesan bahwa ada lebih banyak ... Debian menggunakan sistem berbasis surat , meskipun lebih kompleks daripada milis. Oke, tapi intinya adalah 'apa keuntungan menggunakan milis daripada pelacak bug?' Kecuali jika jawabannya adalah "tidak ada, pengembang git hanyalah luddites".
naught101

@ naught101: mengapa Anda terpesona saat melihat itu? Debian unstable dapat diinstal dan digunakan tanpa melihat eksploit root remote yang membutuhkan patching dan tanpa perlu reboot selama enam bulan dengan mudah. Itu untuk versi Debian yang tidak stabil . Saya punya server Debian yang terkunci yang mencapai uptime 4-digit hari (bukan eksploit root tunggal yang membutuhkan reboot yang memengaruhi pengaturan saya selama periode itu). Orang-orang ini mungkin tidak menggunakan mode teknologi terbaru, tetapi mereka jelas melakukan hal yang benar. Saya akan menyerah pelacak bug web untuk stabilitas Debian kapan saja.
Cedric Martin

2
@CedricMartin: Saya tahu, saya setuju. Pelacakan bug milis jelas berfungsi dengan baik untuk beberapa tim, tetapi bagi saya tampaknya masih tidak semudah pelacak bug. Namun saya telah berpikir, bahwa untuk pengembang proyek inti, perbedaannya mungkin tampak sangat kecil: mereka mengikuti hampir semua yang terjadi. Tetapi bagi pendatang baru, milis hampir tidak mungkin dilakukan, jadi tidak ada gambaran sederhana tentang kesesuaian proyek yang bisa didapat. Pelacak bug memungkinkan pengguna / pengembang baru dengan cepat mengetahui bagaimana suatu proyek bergerak, dan mendapatkan gagasan tentang jenis perbaikan apa yang dianggap penting oleh tim inti.
naught101

Greg Kroah-Hartman telah mengambil ini karena berkaitan dengan Kernel Linux sebagai bagian dari diskusi ini . Secara khusus: "Tidak ada cara model github / gerrit / gitorious akan bekerja sama sekali untuk kernel. Skala di mana kami bekerja adalah tingkat yang sama sekali berbeda dari yang bisa ditangani oleh alat-alat itu. ... Benar-benar tidak ada yang lain cara yang dikenal untuk menangani 10.000 tambalan setiap 2 bulan, dalam rilis yang stabil, dengan peer review, dengan lebih dari 3000 pengembang, selain dari apa yang kami lakukan hari ini. "
naught101

Jawaban:


45

Preferensi yang Anda amati terlihat sebagai konsekuensi alami dari rekomendasi yang dinyatakan dengan jelas dalam Standar Pengkodean GNU . Disarankan untuk melaporkan bug melalui email, seperti yang Anda lihat di kutipan di bawah ini (saya menandai bagian tebal yang secara langsung menangani pengamatan Anda):

4.7.2 --help

--helpOpsi standar harus menampilkan dokumentasi singkat tentang cara menjalankan program, pada output standar, kemudian keluar dengan sukses. Opsi dan argumen lain harus diabaikan begitu ini terlihat, dan program seharusnya tidak menjalankan fungsi normalnya.

Menjelang akhir ‘--help’output opsi, silakan letakkan baris yang memberikan alamat email untuk laporan bug , halaman utama paket (biasanya ‘http://www.gnu.org/software/pkg’, dan halaman umum untuk bantuan menggunakan program GNU. Formatnya harus seperti ini:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

Tidak masalah menyebutkan milis lain yang sesuai dan halaman web.

Preferensi di atas, pada gilirannya, mencerminkan penerimaan universal terhadap email sebagai bentuk komunikasi elektronik. Setiap pengguna yang membaca --helppesan seperti yang disarankan di atas seharusnya dengan mudah memahami apa yang harus dilakukan jika mereka melihat kiriman bug itu mudah.

Pelacak isu mungkin (dan saya pikir adalah ) lebih baik untuk pengembang bekerja di proyek, tetapi untuk audiens yang lebih luas akan sulit untuk menyajikan dan menjelaskan bagaimana menggunakannya, terutama dengan berbagai akun dan perbedaan antara yang berbeda sistem pelacakan masalah .

Satu proyek dapat menggunakan Bugzilla, yang lain akan tetap dengan JIRA, ketiga dengan ... GNATS , dll, dll. Tidak ada cara untuk menyajikan semua "kebun binatang" ini dengan cara yang akan menjadi standar dan seragam seperti

Report bugs to: mailing-address


Catatan di atas tidak berarti bahwa proyek tidak boleh menggunakan pelacak masalah secara internal . Sebagaimana dijelaskan dalam jawaban yang sangat baik untuk pertanyaan terkait ,

Pelacak bug Anda adalah untuk kenyamanan Anda , bukan untuk pelanggan Anda. Jika Anda tidak dapat repot-repot mengambil masalah ponsel atau email dan memasukkannya sendiri, bagaimana menurut Anda perasaan mereka?

Anda harus dapat memasukkan masalah dan menetapkannya secara manual ke klien ...


3
Jawaban bagus! Email lebih dikenal daripada pelacak isu, dan lebih mudah dipahami (yang tidak berarti semua orang "mendapat" email: P)
Andres F.

21
Juga, saran GNU itu kuno, jauh lebih tua dari pelacak isu berbasis web dan web.
Ross Patterson

@ RossPatterson saya sedang memikirkan itu. Tapi sepertinya tidak mungkin itu lebih tua dari web, mengingat mengandung banyak URL ...
naught101

6
@gnat: Bagian utama dari jawaban tertaut yang begitu hebat adalah bagian "jika mudah bagi Anda, Anda dapat memasukkan hal semacam itu di sana" . Itu adalah kunci bagi banyak proyek sumber terbuka, karena tidak ada dana untuk dukungan telepon. Milis adalah kesalahan bagi saya sebagai pengguna pelaporan bug, karena saya tidak mau harus mendaftar untuk mendapat tanggapan. Dengan pelacak kutu, saya dapat melihat bahwa masalah yang saya miliki ada di sistem, dan dapat kembali dan mencarinya nanti, dan melihat apakah sudah diperbarui. Ini sulit dengan milis, kecuali ada pelacak daftar berbasis web yang sangat bagus, yang sering kali tidak demikian.
naught101

1
@ naught101 Ini mungkin tidak lebih tua dari Web tapi jelas lebih tua dari pelacak berbasis Web
sakisk

30

Dengan Git, khususnya, ada alasan historis yang sederhana: Git dimulai oleh peretas Linux untuk peretas Linux, dan ia menggunakan model dan alat pengembangan yang sama seperti Linux itu sendiri. Linux, bagaimanapun, lebih tua dari WWW, jadi, ketika Linux dimulai tidak ada pelacak isu berbasis web, karena tidak ada web!

Sebagai akibatnya, komunitas Linux telah mengembangkan alat dan alur kerja yang sangat efisien untuk menangani laporan bug dan ulasan kode melalui email, dan tidak ada alasan bagi mereka untuk membuang semua pekerjaan itu dan mulai dari awal ketika mereka memulai proyek Git.


3
Saya pikir WWW mendahului Linux. Sedikit. Keduanya sangat banyak dilakukan pada waktu yang bersamaan dan oleh berbagai kelompok orang; Tidak sampai pertengahan 90-an yang lepas landas.
Donal Fellows

6
Ok, tetapi kernel linux sekarang memiliki pelacak bug: bugzilla.kernel.org . Jelas itu bukan penghalang besar.
nucky101

7
-1 Git lebih muda dari web. Vintage 2005. Ada banyak pelacak masalah pada saat itu, termasuk tentu saja Bugzilla. Linus tidak suka pelacak isu, dan kata-katanya adalah hukum di lingkungan itu.
Ross Patterson

6
@RossPatterson - Dia mengatakan Linux lebih tua dari web, bukan Git. Saya tidak berpikir komentar Anda membenarkan pemungutan suara, karena pada dasarnya Anda mengulangi apa yang dia katakan.
beatgammit

2
@jameson Di belakang, Anda benar. Kembali ke netral.
Ross Patterson

17

Untuk Git:

Ada beberapa diskusi di milis tempat orang mengusulkan untuk menggunakan semacam pelacak bug. Inisiatif-inisiatif ini tampaknya semua gagal, sehingga alasan Git tidak menggunakan pelacak bug mungkin karena sebagian besar kontributor tidak menganggapnya berguna.

Dalam sebuah posting di milis , Junio ​​C Hamano (pengelola Git) menyimpulkan mengapa ia merasa pelacak bug tidak terlalu berguna. Saya tidak ingin menyertakan seluruh pos (cukup panjang), tetapi intinya adalah:

  • Jika Anda hanya mencari informasi tentang masalah yang diselesaikan, mencari arsip daftar berfungsi sama seperti mencari pelacak bug.
  • Jika Anda melaporkan bug asli, dan orang-orang ingin membereskannya, daftar itu juga berfungsi dengan baik.
  • Jika tidak ada yang tertarik untuk mengerjakan suatu masalah, itu akan jatuh melalui celah, bahkan dalam pelacak bug.
  • Pelacak bug akan menjadi satu lagi sistem yang perlu dipelihara, diperiksa untuk bug baru secara teratur, telah diperbaiki bug dll, singkatnya, pekerjaan ekstra untuk sedikit manfaat.

5
Jawaban yang bagus, tetapi saya berpendapat bahwa poin ke-3 Anda adalah kelemahan utama dari email: Jika bug sulit untuk diperbaiki dan pengembang saat ini malas, maka secara signifikan lebih terkubur daripada entri dalam pelacak masalah. Ini bisa berarti bug tertentu tidak pernah diperbaiki, hanya karena orang tidak tahu mereka ada di sana
TheLQ

1
@TheLQ: Benar. Namun, tampaknya itu adalah risiko yang bersedia diambil beberapa proyek. Dan agar adil, git adalah perangkat lunak yang cukup solid, bahkan tanpa pelacak bug.
sleske

1
@TheLQ: Bukankah halaman web sederhana yang menyebutkan semua bug yang diketahui (Dan utas terkait) menyelesaikannya? Sesuatu yang mirip dengan ini kecuali tautannya menunjuk ke arsip arsip.
Hello World

1
@ HaloWorld: Ya, itu akan menjadi pelacak isu (sederhana). Dan seperti pelacak masalah, seseorang harus mengelolanya ...
sleske

Apakah ada cara yang baik untuk mendapatkan salinan offline email yang dikirim saat saya bukan pelanggan?
PSkocik

6

Debian memang menggunakan pelacak bug, antarmuka defaultnya adalah email. Dan itu nyaman. Lucas Nussbaum, Pemimpin Proyek Debian saat ini, memposting beberapa hari yang lalu :

debbugs adalah bagian dari perangkat lunak di balik Debian Bugs Tracking System (BTS). Ini juga digunakan oleh proyek GNU. Meskipun sering dianggap sebagai gaya lama, fitur beberapa fitur unik, seperti pelacakan status bug di setiap versi dan cabang paket), atau kemampuan untuk melakukan semua interaksi melalui email, membuatnya sangat mudah untuk bekerja offline atau di lingkungan yang tidak terhubung dengan baik.

Bagian terakhir adalah fitur pembunuh di sini - antri saja laporan itu dalam antrian surat lokal Anda sampai Anda turun dari pesawat!


4
  • Menghindari anak berusia 9 tahun.
  • Tidak perlu membuat akun terpisah untuk setiap forum.
  • [minor] Pengalaman pengguna yang konsisten di milis yang berbeda dan kurva belajar nol saat berlangganan ke daftar baru.
  • Bekerja offline. Anda dapat terhubung ke Internet dan mengunduh banyak surat, lalu pergi hiking, menulis balasan Anda sambil menikmati alam ibu dan mengirimkannya nanti.
  • Mengizinkan penyandian surat dan / atau penandatanganan melalui GPG.
  • Terdesentralisasi - Jika forum macet, Anda masih memiliki salinan, juga rusak, moderator / peretas jahat tidak dapat dengan mudah merusak apa yang Anda katakan. Tidak ada yang bisa membatalkan sejarah.
  • Mengizinkan filter, folder, dan semua fitur organisasi lanjutan dari klien Email.
  • "Pemberitahuan push" - Anda dapat membiarkan klien Email Anda terbuka dan mendapatkan pemberitahuan balasan baru.
  • Satu tempat untuk mengatur semuanya - tidak perlu melompat di antara situs yang berbeda.
  • Kebal terhadap semua kerentanan keamanan yang melibatkan web (html / javascript / suntikan, dll)
  • No bloat - Tidak ada lencana, tanda tangan bergerak mewah, iklan, suar web, bloav javascript. Semuanya sederhana dan to the point - diskusi.
  • Lebih sedikit beban server daripada pengaturan LAMP.

Salah satu kelemahan milis yang muncul dalam pikiran adalah bahwa forum dapat dibagi menjadi beberapa kategori dan subkategori sedangkan milis tidak. Ini dapat ditiru dengan membagi milis menjadi beberapa milis, dan kemudian pengguna dapat menggunakan filter yang sesuai untuk menempatkan setiap pesan dengan folder yang sesuai (Setiap folder menjadi kategori). Di forum web, ini otomatis.


mengapa orang bersikeras membuat versi berbasis web untuk melacak masalah (BTW pertanyaan ini bukan tentang segalanya ) dibahas dalam pertanyaan lain: Membuat pengguna menulis laporan bug yang layak dan bermanfaat "Laporan bug daring yang dapat diedit pengguna adalah cara paling efisien untuk mengajar pengguna meningkat ... "
agas

Terima kasih. Tetapi apakah ini membenarkan downvote? Topik utama dari jawaban ini adalah keunggulan ML, dan itu menjawab pertanyaan asli dengan cukup baik. Saya telah menghapus kata-kata kasar "forum web".
Hello World

2
Kerugian yang disebutkan dalam jawaban ini sebenarnya secara fundamental menghalangi saya untuk bertahan dengan sebagian besar daftar mail dev. Mereka mengirim semuanya , jadi setelah melaporkan bug saya biasanya berhenti berlangganan hanya dua minggu kemudian. Bugtrackers dengan baik menyelesaikan masalah ini dengan membiarkan saya berlangganan laporan bug tertentu.
Roman Starkov

6
Koreksi: mencegah anak berusia 25 tahun. Hanya baru-baru ini saya belajar bagaimana hal-hal milis bekerja untuk berkontribusi pada beberapa proyek nyata . Dan aku benci itu !!
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件

2
"Tidak perlu membuat akun terpisah untuk setiap forum." - Sering kali untuk mencegah spam, Anda perlu mendaftar untuk daftar. Tapi itu berlangganan semua email. Jadi, Anda perlu berlangganan DAN keluar dari 'spam' DAN menambahkan permintaan agar Anda tetap di CC atau TO. Dibandingkan dengan bugzilla, lebih banyak yang harus dilakukan.
Maciej Piechotka
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.