Dari penerjemah: teks ini adalah terjemahan dari posting blog pribadi oleh Michael Stapelberg, pengembang open source terkemuka ( profil GitHub ), yang memberikan kontribusi signifikan terhadap pengembangan Debian.
Posting ini sulit untuk ditulis dari sudut pandang emosional, tetapi saya tidak membatasi diri pada "surat pendek, karena saya tidak punya waktu." Tolong, sebelum membaca teks ini, perlu diingat bahwa saya menulisnya dengan niat terbaik dan jangan menetapkan diri saya tujuan demotivasi atau meremehkan kontribusi salah satu pengembang. Sebaliknya, saya ingin menjelaskan mengapa tingkat frustrasi saya melebihi semua nilai yang dapat diterima.
Debian telah menjadi bagian dari hidup saya selama 10 tahun.
Beberapa minggu yang lalu, pada pertemuan Debian di Zurich, saya bertemu dengan teman-teman lama saya yang tidak pernah saya temui selama bertahun-tahun. Ketika saya sudah mengendarai sepedaku pulang, saya sadar bahwa semua topik yang telah kita diskusikan sampai pada apa yang kita diskusikan dengan mereka sebelumnya. Kami membahas manfaat systemd, yang sekali lagi menarik perhatian komunitas open source, menyentuh topik proses dalam Debian. Puncaknya adalah diskusi tentang demokrasi seperti itu dan kesalahan teoritis dan praktis yang sesuai. Tapi, sebenarnya, ini adalah topik murni Swiss.
Ini bukan review dari mitap masa lalu, saya hanya ingin menjelaskan apa yang membuat saya berpikir tentang sikap saya saat ini terhadap Debian dan apakah itu cocok untuk saya.
Jadi, saya membuat keputusan yang harus saya buat sejak lama: Saya membatasi partisipasi saya dalam pengembangan Debian.
Apa artinya ini?
Dalam beberapa minggu mendatang, hal-hal berikut akan terjadi:
- Saya akan meneruskan paket-paket penting ke perintah yang dipertahankan;
- Saya akan menghapus diri saya dari paket Pengunggah yang berisi pengelola lain;
- paket di mana saya adalah satu-satunya pengawal akan menjadi yatim piatu.
Saya akan mencoba untuk terus mempertahankan halaman
manpages.debian.org dan layanan
codesearch.debian.net , tetapi saya akan sangat menghargai bantuan apa pun di bidang ini.
Jika Anda memiliki pertanyaan atau tugas apa pun, pertimbangkan bahwa saya sedang berlibur tanpa batas waktu. Saya akan mencoba mengambil bagian dalam beberapa masalah administrasi (misalnya, pengalihan izin) dan tugas-tugas yang ditujukan secara pribadi kepada saya, tetapi hanya jika itu tidak memakan banyak waktu.
Mengapa
Ketika saya bergabung dengan Debian, saya masih belajar, yaitu, saya memiliki banyak waktu luang. Sekarang, setelah lima tahun penuh, saya telah belajar banyak - baik dalam hal bagaimana dan apa yang bekerja dalam proyek pengembangan perangkat lunak besar, dan dalam hal memahami preferensi pribadi saya dalam sistem komputer. Sekarang saya jelas menyadari apa yang saya habiskan di sebagian kecil waktu senggang saya dan apa yang tersisa di akhir hari.
Setiap bagian berikut akan fokus pada hal-hal yang menyakiti saya sebagai pengembang. Daftar ini diberikan secara acak. Beberapa masalah ini saling mempengaruhi, misalnya - jika perubahan sistem dilakukan dengan lebih baik, kita akan memiliki peluang bahwa paket akan lebih mudah ditangani oleh mesin.
Proses Perubahan Debian
Selama beberapa tahun terakhir, tim saya saat ini telah mengerjakan berbagai reorganisasi di seluruh basis kode (yang memengaruhi ribuan proyek), jadi kami telah menerima banyak pelajaran berharga tentang cara membuat perubahan ini secara efisien. Saya kesal karena Debian bekerja di hampir semua hal dengan cara yang hampir berlawanan. Saya menghargai kenyataan bahwa setiap proyek berbeda, tetapi saya pikir banyak poin yang tercantum di bawah ini berlaku untuk Debian secara keseluruhan.
Di Debian, pengembangan paket menuju ke arah yang benar menggunakan dokumen yang disebut Kebijakan Debian, atau versi perangkat lunaknya
, Lintian .
Terlepas dari kenyataan bahwa serat sangat nyaman untuk mendapatkan umpan balik langsung atau lokal / otonom yang cepat, lebih baik tidak memerlukan alat seperti itu sama sekali. Sebagai contoh, perintah C ++, yang memperkenalkan bendera keamanan baru untuk semua paket, juga harus dapat membuatnya berfungsi transparan (
dilihat dari profil GitHub, bahasa utama Go adalah Michael, kira-kira Trans. ).
Sebaliknya, sekarang semua paket dilakukan "kotor" (asal - lint-najis): semua petugas harus membaca apa hal baru ini, bagaimana hal itu bisa pecah, apakah itu mempengaruhi pekerjaan mereka secara umum, dan jika demikian, bagaimana. Maka Anda perlu secara manual menjalankan beberapa tes dan, akhirnya, buang perubahannya. Semua ini adalah banyak operasi mekanis overhead dan manual antar paket.
Dalam model Debian,
keputusan untuk meluncurkan berita ada pada paket yang menyertainya, dan bukan dengan pengembang. Di pekerjaan utama saya, kami menemukan bahwa lebih efisien untuk melakukan yang sebaliknya: jika perubahan tertulis memengaruhi sebagian besar pengguna, maka pengembanglah yang harus memutuskan perlunya penerapannya. Pendekatan ini membuat pengembangan proyek lebih efisien dan mengurangi waktu dan biaya tenaga kerja. Tentu saja, ada pengecualian, misalnya, di daerah yang luas di mana chip bahasa digunakan, yang harus dijaga oleh masing-masing kurator pemilik, tetapi yang penting adalah bahwa secara default semuanya harus berbeda dari yang ada sekarang.
Debian
tidak memiliki alat untuk membuat perubahan besar : secara program sulit untuk bekerja dengan paket dan repositori yang terfragmentasi (lebih lanjut tentang ini di bagian di bawah). Peristiwa terdekat dengan "pengiriman perubahan ke ulasan" default adalah proses membuka laporan bug dengan tambalan yang melekat padanya. Tampaknya bagi saya bahwa proses yang ada untuk menerima perbaikan bug terlalu rumit, dan saya mulai mengerjakan bot gabungan, tetapi hanya Guido dan tidak ada orang lain yang menunjukkan minat padanya (
tampaknya, penulis berbicara tentang Guido agx Gunter , pengembang Debian lain, - kira-kira .
Singkatnya, reaksi terhadap dorongan dan, karenanya, penerimaan umpan balik lambat. Tidak ada tenggat waktu. Terkadang saya mendapat email yang memberitahukan bahwa tambalan yang saya kirim beberapa tahun yang lalu (!!!) akhirnya terkandung. Ini membentang proyek-proyek mingguan selama bertahun-tahun, yang bagi saya adalah demotivator yang kuat.
Sangat menarik untuk dicatat, tetapi praktik aktivitas online kura-kura juga diproyeksikan pada budaya offline, dan saya tidak ingin membahas keunggulan systemd 10 tahun setelah saya pertama kali mendengarnya.
Dan akhirnya, setiap perubahan bisa terhenti oleh mereka yang tidak setuju, yang akhirnya menolak untuk bekerja sama. Contoh kanonik saya tentang situasi ini adalah rsync. Kurator menolak tambalan saya, yang menambahkan dukungan debhelper ke paket, semata-mata dari keyakinan mereka sendiri.
Memberikan tingkat kebebasan pribadi kepada pengelola individu sedemikian rupa mencegah kita semua peserta proyek meningkatkan tingkat abstraksi bangunan Debian, yang, pada gilirannya, memperumit alat pengembangan.
Seperti apakah itu semua di dunia yang ideal?
- Sebagai sebuah proyek, kita harus berjuang untuk penyatuan. Bagaimanapun, penyatuan tidak mengecualikan eksperimen, melainkan hanya mengubah kompromi saat ini antara eksperimen yang lebih sederhana dan otomatisasi yang lebih kompleks menjadi kompromi antara eksperimen yang lebih kompleks dan otomatisasi yang lebih sederhana.
- Budaya pengembangan kita harus menjauh dari paradigma “paket ini adalah bisnis saya, beraninya Anda menyentuhnya”, rasa kepemilikan bersama, di mana setiap peserta dapat dengan mudah membuat atau memverifikasi perubahan, bahkan tanpa melibatkan kurator khusus yang menyertai mereka.
Untuk memahami seperti apa perubahan besar yang berhasil itu, saya sarankan Anda membaca presentasi rekan saya Hiram Wright
"Perubahan Besar-Besaran di Google: Pelajaran dari Migrasi Massal Lima Tahun" .
Alur kerja dan infrastruktur yang terfragmentasi
Debian biasanya lebih suka pendekatan desentralisasi daripada yang terpusat. Sebagai contoh, paket terpisah disimpan dalam repositori terpisah, dan setiap repositori dapat menggunakan SCM (biasanya git dan svn) atau tidak sama sekali. Plus, setiap repositori dapat di-host di situs mana pun. Tentu saja, isi dari masing-masing repositori juga sedikit berbeda dari satu tim ke tim lainnya, dan bahkan di dalam tim.
Dalam praktiknya, opsi hosting non-standar jarang digunakan, karena mereka tidak membenarkan biayanya, tetapi sering kali cukup menyakitkan ketika mencoba mengotomatiskan proses membuat perubahan pada paket. Jadi, alih-alih menggunakan API GitLab untuk membuat permintaan penggabungan, Anda perlu mengembangkan sistem yang sama sekali berbeda, lebih kompleks yang bekerja dengan repositori yang tidak dapat diakses secara berkala (atau terus-menerus!), Mengabstraksi perbedaan dalam tambalan yang dikirimkan (laporan kesalahan, menggabungkan permintaan , permintaan ekstraksi) dan seterusnya dan seterusnya ...
Proses pembangunan yang sangat berbeda bukan hanya buang-buang waktu. Saya berpartisipasi dalam diskusi panjang tentang berbagai proses pengembangan git selama DebConf 13 dan saya menyadari bahwa diskusi serupa sedang diadakan saat itu.
Secara pribadi, saya tidak dapat mengingat cukup detail tentang berbagai metodologi pengembangan. Setiap kali saya menyentuh paket yang tidak berfungsi seperti milik saya, saya menjadi sangat kesal karena saya harus memeriksa kembali aspek-aspek pekerjaannya.
Saya melihat fragmentasi serupa alur kerja di tim pengemasan Go saya sendiri dan mencoba memperbaikinya dengan
membuat saran untuk perubahan alur kerja , tetapi saya tidak bisa menerapkannya. Kurangnya otomatisasi yang efektif dan rendahnya perubahan alat, meskipun kesediaan saya untuk menghabiskan waktu dan energi saya sendiri, membunuh motivasi apa pun.
Infrastruktur yang sudah tidak digunakan lagi: Paket Unduhan
Ketika Anda ingin membuat paket tersedia di Debian, Anda mengunggah file yang ditandatangani GPG melalui FTP anonim. Ada beberapa jenis tugas (daemon antrian, tidak dicentang, dinstall, dan lainnya) yang berjalan pada jadwal tetap (misalnya, dinstall berjalan pada 01:52 UTC, 07:52 UTC, 13:52 UTC, dan 19:52 UTC).
Saya menghitung bahwa tergantung pada waktu hari, Anda dapat menunggu lebih dari 7 jam (!!!) sebelum paket Anda diinstal.
Tetapi bagian terburuk bagi saya adalah bahwa umpan balik tidak sinkron sehubungan dengan memuat. Saya suka melakukan sesuatu, akhiri dan lanjutkan ke tugas berikutnya. Pengaturan saat ini membutuhkan waktu lama dan, pada kenyataannya, pergantian tugas yang mahal tanpa alasan teknis yang baik. Anda mungkin memperhatikan bahwa beberapa menit tidak terlalu penting, tetapi ketika semua waktu dalam sehari yang dapat saya habiskan untuk Debian diukur dalam beberapa menit, sangat penting untuk merasakan kinerja dan kepuasan saya sendiri dari pekerjaan yang dilakukan.
Pesan terakhir yang dapat saya temukan tentang mempercepat proses ini adalah sebuah
posting oleh George Ganneff Jaspert dari 2008.
Seperti apakah itu semua di dunia yang ideal?
- FTP anonim akan digantikan oleh layanan web yang menerima paket saya dan mengembalikannya sebagai keputusan resmi untuk menerima atau menolaknya.
- Untuk paket yang diterima, ada halaman yang menampilkan status build dan waktu ketika paket akan tersedia melalui jaringan mirror.
- Paket harus tersedia dalam beberapa menit setelah penyelesaian perakitan.
Infrastruktur yang sudah tidak digunakan lagi: Pelacak Bug
Saya takut berinteraksi dengan pelacak bug Debian. Debbugs adalah potongan kode langsung dari 1994 yang saat ini hanya digunakan oleh Debian dan proyek GNU.
Proses debbugs didasarkan pada penggunaan e-mail, yaitu, mereka tidak sinkron dan rumit. Terlepas dari kenyataan bahwa ini bekerja pada mesin tercepat yang kami miliki di proyek Debian (well, mereka mengatakan kepada saya ketika topik ini terakhir diangkat), antarmuka webnya memuat sangat lambat.
Khususnya, antarmuka web di bugs.debian.org hanya-baca.
Menyiapkan ruang kerja email untuk
reportbug (1) atau bekerja secara manual dengan lampiran adalah tantangan yang cukup serius.
Untuk beberapa alasan yang saya tidak mengerti, setiap interaksi dengan debbugs mengarah ke
banyak percakapan .
Selain implementasi teknis, saya juga tidak dapat mengingat dengan cara apa pun berbagai cara di mana Debian menggunakan paket pseudo generation untuk kesalahan dan proses. Saya jarang membutuhkannya sehingga saya akhirnya meletakkan semuanya di kepala saya dan ingat bagaimana mereka berfungsi dan digunakan, tetapi saya kadang-kadang bertemu mereka, jadi varietas ini mengganggu.
Seperti apakah itu semua di dunia yang ideal?
- Debian akan beralih dari cara pelacakan bug yang tidak standar ke (apa saja) yang sudah diselesaikan.
- Debian mengotomatiskan proses ini. Antarmuka utama harus lebih nyaman (misalnya, formulir web).
Infrastruktur yang sudah tidak digunakan lagi: Arsip Korespondensi Email
Saya bingung dengan kenyataan bahwa pada tahun 2019 kami masih belum memiliki alat yang nyaman untuk melihat utas diskusi arsip di surat. Sebanyak di Debian, Email dan percakapan tidak lagi digunakan di mana pun, jadi bahkan agak ironis. Menggunakan
Gmane tampaknya untuk menyelesaikan masalah ini, tetapi ketersediaannya selama beberapa tahun terakhir telah, secara sederhana, tiba-tiba (sekarang, pada saat menulis posting ini, tidak berfungsi sama sekali).
Saya mencoba membuat arsip multi-utas, tetapi master sheet kami tidak terkesan dan menolak untuk mendukung proyek.
Sulit bagi mesin untuk bekerja dengan Debian
Meskipun jelas bahwa Anda dapat bekerja dengan paket Debian secara terprogram, pengalaman ini tidak menyenangkan. Segalanya tampak lambat dan besar. Saya memilih tiga contoh kecil untuk menggambarkan posisi saya dalam masalah ini.
debiman membutuhkan
bantuan dari bagian-bagian dalam menganalisis mekanisme alternatif dari setiap paket untuk menampilkan halaman dokumentasi, misalnya,
PSQL (1) . Ini diperlukan karena skrip memodifikasi database alternatif dengan memanggil skrip shell. Tetapi tanpa benar-benar menginstal paket, Anda tidak akan tahu perubahan apa yang dibuatnya.
pk4 harus memelihara cache sendiri untuk mencari paket metadata berdasarkan namanya. Alat-alat lain menganalisis database apt dari awal dengan setiap panggilan. Format database yang benar, atau setidaknya format pertukaran biner, akan sangat penting untuk proses ini.
Pencarian Kode Debian ingin menerima paket baru secepat mungkin.
Instans fedmsg sebelumnya digunakan, tetapi tidak lagi ada. Tidak jelas di mana menerima pemberitahuan paket baru dan di mana yang terbaik untuk menerimanya.
Tumpukan build kompleks
Di sini Anda dapat membaca posting saya
“Alat Pembuatan Paket Debian” . Yang benar-benar membuat saya khawatir adalah kenyataan bahwa menambah jumlah alat tidak dianggap masalah.
Debian adalah pengalaman yang menyakitkan bagi pengembang
Sebagian besar pertanyaan yang saya ajukan berkaitan dengan pengalaman pengembangan Debian, tetapi seperti yang baru-baru ini saya jelaskan dalam posting saya
, Pengalaman Debian Debugging , pengalaman pengembangan
menggunakan Debian juga meninggalkan banyak hal yang diinginkan.
Saya punya banyak ide
Artikel itu ternyata sangat banyak, tetapi saya harap Anda mendapat perkiraan tentang motivasi saya.
Meskipun saya menggambarkan sejumlah kelemahan spesifik di atas, paku terakhir di tutup peti mati adalah kurangnya pandangan positif untuk masa depan. Saya memiliki ide lain yang tampaknya sangat meyakinkan bagi saya, tetapi berdasarkan pada bagaimana kemajuan proyek saya sebelumnya, saya tidak berpikir saya dapat mengimplementasikannya sebagai bagian dari proyek Debian.
Saya bermaksud memposting beberapa posting lagi tentang cara-cara khusus untuk meningkatkan sistem operasi di blog saya. Jadi mampir.
Dan akhirnya, saya berharap posting ini menginspirasi seseorang, idealnya sekelompok orang, untuk membuat kehidupan pengembang Debian lebih baik.