Kolom Baru di Blog ini adalah TOKOH, yang diharapkan mampu menginspirasi para pengembang dan aktivis di tanah air untuk melakukan pencapaian yang sama. Semoga manfaat.
Mengenal Tokoh Debian : Philipp Kern, Manajer Rilis Stabil
(Bagian Pertama dari 2 Tulisan)
Wawancara oleh : Raphaël Hertzog – www.raphaelhertzog.com
Terjemah Bebas oleh Pengelola Blog http://tanyarezaervani.wordpress.com
Philipp adalah pengembang Debian semenjak 2005 dan anggota tim rilis semenjak tahun 2008. Semenjak ia mengemban tanggung jawab sebagai Manajer Rilis Stabil, proses yang ada telah berkembang menjadi yang terbaik. Kami meminta kepadanya untuk menjelaskan bagaimana tim rilis memutuskan sebuah versi stabil atau tidak.
Karya lainnya yang menakjubkan adalah infrastruktur buildd, tapi saya akan membiarkan dia saja yang memaparkannya. Pertanyaan saya ditulis dengan huruf tebal, sementara yang lainnya adalah jawaban dari Philipp
Bisa Kenalkan Diri Anda ?
Saya mahasiswa Ilmu Komputer berusia 24 tahun. Tinggal di Karlsruhe, Jerman.
Sebagai asisten mahasiswa saya saat ini memiliki dua tanggung jawab : yang pertama membentuk jaringan IPv6 di universitas, atau secara lebih umum memasukkan teknologi tersebut ke dalam jaringan. Yang kedua adalah merawat mesin s390x yang diterima oleh fakultas saya baru-baru ini.
Di waktu luang, saya lebih banyak melakukan tugas-tugas Debian dan aktif pula di dewan mahasiswa (Fachschaft) sebagai sys-admin, pengembang perangkat lunak dan baru-baru ini ditunjuk sebagai bendahara.
Saya diterima sebagai pengembang Debian pada tahun 2005. Saya baru benar-benar aktif ketika diundang untuk bergabung ke tim rilis pada awal 2008 setelah berkontribusi menulis ulang beberapa script yang hilang dalam insiden disk-crash di master FTP. Pada akhir tahun 2008, saya juga menerima tanggung jawab untuk wanna-build/buildd.
Apa Pencapaian Anda yang Berarti Bersama Debian ?
Saat saya bekerja untuk memindahkan suatu kombinasi tunggal buildd/sbuild ke semua buildd yang ada. Saya melakukan basis ulang kombinasi tunggal tersebut pada sbuild dalam arsip beberapa kali. Semua buildds pada dasarnya terlihat sama pada semua arsitektur, dengan hanya sedikit variasi. chroot juga kini dibuat dengan cara yang sebagian besar dapat diprediksi.
Kemudian, kami akhirnya dapat membuat autosigning setelah selama bertahun-tahun berada dalam kendala yang terus terjadi berulang-ulang. Bagaimanapun keputusan pada kebijakan yang dikeluarkan untuk memperkenankannya dibuat oleh ftp-master, sangat saya syukuri, karena sedikit mengurangi beban maintainer buildd, tim Security dan tim rilis.
Di sisi rilis ada integrasi volatile kedalam struktur debian yang tepat. Tetapi disana saya melakukan kesalahan pada penamaan squeeze-updates yang buruk, jika dibandingkan dengan yang lebih aman squeeze/updates. Kita lihat apakah kami dapat memperbaikinya pada wheezy nanti.
Kebijakan untuk update versi stabil berubah sepanjang waktu. Dapatkah anda membuat intisari update apa saja yang diperkenankan saat ini ?
Semua perubahan yang kami buat pada kebijakan yang ditetapkan dilandasi dengan tujuan untuk menjaga versi stabil yang ada (dan dalam beberapa level yang lebih rendah juga versi oldstable) bisa tetap terpakai sepanjang waktu.
Saya harus mengakui bahwa kami sedikit lebih liberal daripada sebelumnya, setelah saya yang mengambil alih.
Kebijakan update stabil sebelumnya menyertakan perbaikan bug-bug kritis yang dapat merusak sistem dalam cara tertentu dan juga menyertakan perbaikan-perbaikan di sisi keamanan. Kami juga membuka kemungkinan untuk menyertakan perbaikan-perbaikan penting atas bug-bug yang menganggu berdasarkan kasus per kasus.
Seluruh bagian “jangan mengupdate sebanyak itu” pada manajemen rilis stabil didasari pada “mari jangan merubah prilaku dalam menjalankan sistem” dan “mari membuat regresi sesedikit mungkin”.
Kami saat ini mencoba untuk mengantisipasi bahwa dengan suatu proses review, perbaikan konten-mandiri yang diperkenankan hanya yang diuji pertama kali pada versi unstable, jika dapat diterapkan.
Di masa mendatang saya juga ingin memiliki suatu proses feedback yang melibatkan pengguna paket untuk melaporkan masalah-masalah yang ada sesegera mungkin. Pada kenyataannya, itulah mengapa kami kini membuat pengumuman untuk pengujian debian-stable satu minggu lebih cepat (lihat e mail ini sebagai contoh).
Jadi versi stabil diupdate pada titik-titik tertentu, umumnya setiap dua bulan untuk rilis stabil dan sekitar empat bulan untuk versi oldstable. Ditandai dengan pengumuman ketersediaan set CD/DVD yang baru.
Untuk dapat memberikan beberapa update dengan jeda yang sedikit kepada para pengguna dan untuk menghindari mereka harus mengambilnya dari bagian proposed-updates, disediakanlah stable-updates. Kebijakan yang ada sekarang untuk hal ini tersedia pada posting ini di debian-devel-announce. Semua itu mencakup pada hal-hal yang penting seperti tzdata, perbaikan-perbaikan regresi dan paket-paket volatile. Kami menyatakan bahwa beberapa paket berada dalam kondisi stabil hanya jika tidak ada gunanya lagi ketika mereka diupdate melalui volatile, karena mereka dimasukkan kedalam versi stabil pula. Kami juga mengendorkan sedikit aturan yang ada, sehingga paket leaf seperti clive, yang berasal dari website eksternal yang tidak merubah alamat URL mereka, dapat juga diupdate.
Jika seseorang menduga-duga apa yang terjadi pada suatu rilis dan pada “setengah bagiannya lagi” … yang diperuntukkan untuk menandai masuknya dukungan perangkat keras baru (yang kebanyakan berasal dari penyertaan versi kernel co-installable yang baru).
Jenis rilis flag point seperti ini syukurnya tidak lagi diperlukan karena tim kernel kami yang luar biasa kini melakukan backports driver-driver perangkat keras tertentu ke dalam versi kernel yang ada pada rilis stabil. Walaupun tentu saja mereka juga memiliki masalah-masalah yang membutuhkan feedback. Akan sangat baik jika lebih banyak pengguna rilis stabil dapat memberikan respon akan ajakan tim ini untuk melakukan pengujian.
Bersambung (rezaervani@gmail.com)
Leave a Reply