Jika Anda telah mengikuti pengembangan PostgreSQL selama beberapa tahun terakhir, Anda mungkin pernah mendengar istilah manajer commitfest beberapa kali. Anda mungkin sudah tahu apa itu commitfest, tetapi mengapa ada manajer? Karena saya menghabiskan banyak waktu pada Januari lalu untuk mengelolanya, saya akan menjelaskannya.
Patch diterapkan selama commitfest
Pada intinya, commitfest PostgreSQL hanyalah kumpulan tambalan yang menunggu integrasi ke dalam basis kode PostgreSQL. Prinsip kerja commitfest adalah setiap patch yang telah dikirim ke pgsql-hackers harus ditinjau tepat waktu; setelah ditinjau dan direvisi cukup lama, tambalan tersebut akan dimasukkan secara permanen ke dalam PostgreSQL oleh seorang pembuat komitmen.
Adapun alur kerja commitfest:setiap patch baru mulai hidup di commitfest dalam status "perlu ditinjau"; dapat ditutup sebagai "ditolak" (menghancurkan hati penulis yang rapuh), "berkomitmen" (membuat hari, atau minggu, atau bulan penulis), atau "dikembalikan dengan umpan balik" (di mana penulis perlu terus melakukannya, tahu apa yang harus dilakukan untuk meningkatkan tambalan, dan menghidupkannya kembali di commitfest mendatang). Ada juga status berumur pendek, "menunggu penulis", yang digunakan untuk umpan balik cepat yang diharapkan menghasilkan versi baru tambalan dalam beberapa hari lagi sebagai "perlu ditinjau". Selama kami memiliki beberapa hal yang ditandai "berkomitmen" dan penulis mendapatkan umpan balik yang baik, semuanya akan terus berjalan:PostgreSQL tumbuh, berkembang, dan matang untuk menjadi "rilis besar" berikutnya.
Sejauh ini bagus.
Mengapa kita membutuhkan seorang manajer?
Mengelola commitfest
Pembaca yang penuh perhatian mungkin telah memperhatikan bahwa ada tiga kelompok orang yang terlibat dalam proses:penulis tambalan, pengulas, pembuat komitmen. Ada banyak tumpang tindih di antara ketiga kelompok itu, di situlah masalah dimulai. Untuk melakukan tinjauan tingkat kode yang baik, orang perlu memahami kodenya, dan mereka yang melakukannya juga menulis tambalan mereka sendiri. Di sisi lain, pembuat komitmen hanyalah peninjau yang seharusnya memiliki kemampuan lebih baik dalam menemukan dan memperbaiki “masalah” kode. Committer juga selalu menulis patch mereka sendiri.
Masalahnya adalah jika pembuat tambalan terus mengerjakan tambalan mereka sendiri secara eksklusif, mereka tidak akan punya waktu untuk meninjau atau melakukan tambalan orang lain. Ini dapat terjadi dengan mudah jika mereka menerima umpan balik dan segera mengerjakan versi lain yang menghasilkan lebih banyak umpan balik; ini menciptakan loop yang bisa berlangsung sangat lama. Pada titik tertentu, hal yang wajar untuk dilakukan adalah bagi penulis untuk menghapus tambalan dari commitfest dan bekerja untuk meninjau tambalan orang lain; tetapi karena semua orang percaya bahwa patch mereka sangat penting, ini jarang terjadi secara spontan.
Di situlah manajer commitfest memasuki gambar. Salah satu tugas adalah untuk menarik minat dari orang-orang pgsql-hacker untuk benar-benar meninjau tambalan. Sebagian besar waktu, mengirim email publik ke grup sudah cukup untuk membuat orang membaca, berdiskusi, menguji, memikirkan tentang tambalan. Seringkali, pembuat tambalan perlu diingatkan bahwa mereka perlu melihat tambalan orang lain, bukan hanya milik mereka sendiri. Aplikasi commitfest memiliki antarmuka kirim email yang berguna yang dapat digunakan untuk itu. Hal-hal ini biasanya cukup untuk membuat banyak tinjauan silang.
Ada aturan lama yang hampir terlupakan:jika pembuat tambalan tidak melakukan tinjauan, tambalan mereka dapat ditutup dari commitfest tanpa pertimbangan lebih lanjut. Sepengetahuan saya, ini tidak pernah terjadi, yang menyatakan bahwa setidaknya sampai batas tertentu penulis patch adalah “warga negara yang baik”.
Jadi, baik dengan bujukan atau paksaan, manajer commitfest dapat membuat orang meninjau patch, yang sebagian besar tidak akan terjadi secara spontan kecuali ketika peretas sudah bekerja sama.
Di sisi lain, pembuat tambalan terkadang membiarkan tambalan mereka berlama-lama tanpa pembaruan. Salah satu jawaban yang mungkin adalah dengan menutupnya “dikembalikan dengan umpan balik”, tetapi sering kali ada baiknya mendorong penulis untuk mengirimkan versi yang diperbarui.
Manajer commitfest juga dapat menghabiskan banyak waktu untuk melakukan tinjauan mereka sendiri, dan jika mereka memiliki hak komit, melakukan tambalan.
Terakhir, merupakan tanggung jawab manajer commitfest untuk memastikan semua patch ditutup saat commitfest selesai, yang biasanya harus satu bulan setelah dimulai. Untuk tambalan yang telah menerima umpan balik, yang telah ditanggapi oleh penulis dengan versi lain, adalah wajar untuk "memindahkan tambalan ke commitfest berikutnya":janji commitfest (untuk memberikan umpan balik) telah ditepati. Namun, melakukan itu pada tambalan yang belum menerima umpan balik adalah tidak adil. Menutup commitfests menjadi lebih sulit ketika itu terjadi.
Komitfest Januari 2016
Bagan ini menggambarkan commitfest Januari 2016. Datanya dari email status mingguan yang saya kirim:mulai, minggu 1, minggu 2, minggu 3, minggu 4, final.
Anda dapat melihat bahwa kami memulai dengan 85 dalam status "perlu ditinjau" atau "siap untuk pembuat komitmen", yang berarti mereka menunggu orang lain selain penulis untuk bertindak. Satu minggu kemudian kami turun menjadi 71 tambalan pada status tersebut:itu berarti 14 tambalan diproses dalam satu minggu, yang tidak buruk karena, jika dipertahankan, tingkat itu berarti seluruh antrian tambalan akan berakhir hanya dalam 5 minggu lagi.
Namun, selama minggu pertama itu saya melakukan enam tambalan sepele. Itu habis cukup cepat, dan tingkat komit diperkirakan akan menurun. Untungnya, komitter lain bekerja keras, dan Anda dapat melihat bahwa tingkat tambalan yang dilakukan cukup konstan untuk seluruh periode. Hal ini mungkin dapat dicapai di semua commitfest, dengan asumsi persuasi yang sesuai diterapkan pada committer.
Terlihat bahwa status "dikembalikan dengan umpan balik" hanya muncul di akhir commitfest. Ini cukup banyak melanjutkan tren yang terlihat di baris "menunggu penulis". Menurut saya, ini tidak apa-apa. Beberapa orang lebih suka patch tertentu untuk "di-boot" lebih awal, sehingga upaya difokuskan pada patch yang benar-benar memiliki peluang untuk masuk ("triase", jika Anda mau). Saya sendiri tidak yakin tentang itu, jadi saya tidak menerapkan ide itu di sini.
Saya pikir commitfest ini cukup berhasil dalam mendapatkan patch yang dikomit; kemajuan di depan itu pasti terlihat, jika tidak harus sangat besar. Saya juga berpikir itu sangat berhasil dalam memastikan bahwa setiap pembuat tambalan mendapat cukup banyak diskusi tentang tambalan mereka. Jadi, bagi saya, saya puas dengan pekerjaan yang dilakukan.
Saran untuk manajer commitfest masa depan
Menurut saya, memiliki pembaruan status mingguan memberikan hasil yang baik:memberikan kesan kepada semua orang bahwa sesuatu sedang terjadi (yang memang demikian), memotivasi pengulas dan pembuat komitmen untuk melakukan pekerjaan mereka.
Selain itu, saya mengambil pendekatan untuk membuat daftar beberapa tambalan yang membutuhkan perhatian setiap kali — bukan tambalan yang sama setiap waktu, tetapi saya lebih fokus pada set yang berbeda setiap kali, untuk memastikan setiap tambalan yang macet mendapat tendangan di suatu tempat. Ini adalah pekerjaan yang halus:akan lebih mudah untuk hanya membuat daftar semua tambalan yang membutuhkan perhatian, tetapi jika Anda melakukannya, mata akan tertuju pada daftar raksasa dan semuanya terus diabaikan.
Setiap pendapat Anda tentang bagaimana commitfest dikelola akan dihargai; silakan email saya jika Anda tidak ingin mempostingnya secara publik sebagai komentar. Jika menurut Anda hal-hal yang saya lakukan tidak efektif, atau jika Anda memiliki ide lain tentang apa yang harus dilakukan, saya bersedia mendengarkan. Saya dapat mengelola commitfests lain di masa mendatang, jika sumber daya memungkinkan.
Terakhir, persiapkan diri Anda untuk commitfest Maret 2016 mendatang. Ini akan menjadi commitfest terakhir untuk 9.6 dan saya yakin akan ada banyak hal yang harus dilakukan untuk semua orang. Selamat meninjau patch!
