Kebijakan pemelihara tidak responsif

Tujuan

Tujuan dari kebijakan ini adalah untuk menyediakan mekanisme di dalam Fedora untuk menangani situasi ketika seorang pemelihara paket menjadi tidak tersedia untuk melanjutkan pemeliharaan, yang sering disebut sebagai \"tidak responsif\". Tujuan akhirnya adalah untuk membantu mencegah paket menjadi usang karena ketiadaan pemeliharaan, mengurangi bug terbuka pada paket yang tidak terpelihara, dan meningkatkan kualitas Fedora secara keseluruhan.

Cakupan

Kebijakan ini mencakup paket, kontainer, dan modul Fedora yang ada; untuk pengirim atau peninjau paket yang tidak responsif, lihat Kebijakan untuk tinjauan paket yang terhenti. Jika Anda bukan kontributor Fedora yang ada, Anda juga dapat mengikuti prosedur ini. Jika Anda ingin mengambil alih pemeliharaan, Anda harus mencari sponsor dengan mengikuti aturan yang ditentukan dalam Cara mendapatkan sponsor untuk masuk ke grup pengemas.

Langkah-langkah

Ketika seorang anggota Fedora menyadari bahwa seorang pemelihara tidak menjawab bug mereka, tidak menjawab permintaan pembangunan ulang, permintaan tarik src.fedoraproject.org, surel, atau sejenisnya, langkah-langkah berikut harus diikuti:

Minggu 0

  1. Periksa apakah pemelihara yang tidak responsif sedang cuti. Untuk melihat apakah pemelihara aktif baru-baru ini di Fedora, fedora-active-user dapat digunakan.

  2. Ajukan bug baru terhadap paket tersebut di Bugzilla meminta pemelihara untuk menanggapi menggunakan templat yang sesuai dan isi semua kolom (templat untuk pemelihara paket tidak responsif, pemelihara kontainer tidak responsif, atau pemelihara modul tidak responsif). Ini adalah sebuah keharusan.

  3. Kirim pesan ke daftar devel Fedora dengan tautan ke laporan bug dan tanyakan apakah ada yang tahu cara menghubungi pemelihara. Tembuskan ke pemelihara. Tautan ke semua laporan bug lain yang terbuka pada semua paket yang terabaikan dari pemelihara yang sama harus disertakan.

Minggu 1

  1. Setelah 7 hari, ajukan isu FESCo dengan tautan bug dan tautan postingan milis. Nyatakan jika Anda seorang pengemas dan ingin mengambil alih paket tersebut. Pemelihara yang tidak responsif dan semua pemelihara yang ada harus disebutkan menggunakan @ dalam tiket tersebut.

  2. Jika setidaknya satu anggota FESCo memberikan suara +1 dan tidak ada yang memberikan suara berbeda, tiket disetujui setelah tiga hari. Jika ada suara -1 atau 0, FESCo akan mendiskusikan masalah tersebut dalam rapat. Kebijakan pemungutan suara ini sengaja dibuat lebih sederhana daripada kebijakan pemungutan suara#ticket-votes yang biasa.

  3. Jika disetujui, dan pelapor adalah pengemas Fedora saat ini yang berstatus baik, yang tertarik untuk menjadi rekan pemelihara paket, FESCo secara default akan menambahkan pelapor sebagai admin paket. Jika rekan pemelihara paket yang ada tidak ingin paket ditugaskan kembali ke pelapor, mereka harus menyatakannya di dalam tiket. Jika diberikan kepemilikan, pelapor sekarang dapat melakukan pemeliharaan paket apa pun yang diperlukan.

Minggu 2

  1. Seminggu kemudian FESCo memposting pengingat di tiket, menyebutkan pemelihara dengan @.

Minggu 3

  1. Tanpa balasan lebih lanjut dari pemilik asli, FESCo menutup tiketnya dan tiket bugzilla. Jika kepemilikan pemeliharaan diminta dalam tiket FESCo, pelapor akan ditugaskan sebagai pemelihara utama paket, dan jika tidak paket akan diyatimkan. Semua paket lain juga diyatimkan, dan dapat diambil oleh rekan pemelihara atau pengemas lain. Pemilik asli dihapus sebagai rekan pemelihara (akses admin/komit/tiket) atau \"pengamat\" dari semua paket lain.

Setelah penugasan ulang akhir terjadi, pemilik baru juga harus menugaskan ulang semua bug terbuka untuk paket ini kepada diri mereka sendiri.

Catatan untuk pemelihara

Dipahami bahwa pemelihara akan pergi berlibur atau sebaliknya tidak akan tersedia dalam jangka waktu yang mungkin cukup lama. Ada beberapa hal yang harus dipertimbangkan oleh pemelihara jika mereka mengetahui sebelumnya bahwa mereka tidak akan tersedia;

  • Tunjuk rekan pemelihara. Secara umum, lebih baik bagi setiap paket untuk memiliki beberapa pemelihara. Rekan pemelihara dapat ditambahkan di tab Pengaturan paket di dist-git.

  • Sunting halaman Liburan (Vacation) untuk menunjukkan kapan Anda akan pergi.

Alamat surel tidak valid

Bugzilla menggunakan alamat surel dalam Sistem Akun Fedora untuk mengirim pesan kepada pemelihara paket. Jika diketahui bahwa alamat surel ini tidak lagi sampai ke pemelihara paket, dan sudah ada prosedur pemelihara tidak responsif yang terbuka, masalah dengan alamat surel tersebut harus dicatat dalam postingan milis dan tiket FESCo. Jika tidak, prosedur pemelihara tidak responsif harus dibuka untuk pemelihara ini.

Situasi di mana diketahui bahwa alamat surel tidak lagi akan sampai ke pemelihara adalah:

  1. Surel ke alamat tersebut memantul (untuk membedakan dari pantulan sementara seperti kotak surat penuh, ini harus berlangsung selama periode 7 hari).

  2. Red Hat memberi tahu kami bahwa alamat surel tidak lagi valid bagi pemelihara paket (biasanya karena orang tersebut telah meninggalkan Red Hat).

Dalam kasus khusus di mana sebuah akun tidak memiliki alamat surel valid yang terhubung di bugzilla, dan tidak memelihara paket apa pun serta bukan bagian dari grup packager, akun tersebut dapat dihapus dari \"pengamat\" paket segera.

Prosedur pengecualian

Ada beberapa kasus di mana mungkin diperlukan untuk menugaskan ulang paket meskipun prosedur ini belum selesai. Contohnya termasuk ketika banyak dependensi rusak, pembaruan versi diperlukan untuk alasan keamanan atau stabilitas, atau tanggapan pemelihara mencegah proses tidak responsif untuk dilanjutkan tanpa benar-benar melanjutkan pemeliharaan. Dalam kasus seperti itu, prosedur pengecualian ini dapat digunakan.

Langkah-langkah:

  1. Jelaskan mengapa proses pengecualian diperlukan dan catat semua upaya komunikasi dalam sebuah surel ke daftar [devel@lists.fedoraproject.org](mailto:devel@lists.fedoraproject.org) dengan pemelihara yang tidak responsif ditembuskan (CC) pada surel tersebut.

  2. Buka tiket FESCo yang dijelaskan pada langkah 4 tanpa menunggu seminggu dan jelaskan juga situasinya di sana.

Proses menyatimkan (orphaning)

Kecuali ada alasan untuk tidak melakukannya (surel pemelihara memantul, pemelihara telah memberi tahu seseorang bahwa mereka tidak tertarik untuk terus memelihara paket Fedora), kami akan menjadikan pemelihara sebagai rekan pemelihara pada paket di semua cabang di mana mereka adalah pemiliknya. Kemudian kami akan menyatimkan paket-paket tersebut.

Jika surel pemelihara memantul atau kami diberitahu bahwa pemelihara tidak tertarik untuk terus berkontribusi pada Fedora, kami akan menghapus semua acl pemelihara tersebut.

Alternatif: Proses permintaan terhenti yang ringan untuk pengemas lain

Proses pemelihara tidak responsif adalah pekerjaan serius, dan jika berhasil, mengakibatkan paket di mana pemelihara tersebut adalah admin utama menjadi yatim; sebagaimana dicatat dalam Prosedur pengecualian tanggapan pemelihara juga membatalkan proses ini.

Prasyarat

  1. Anda harus sudah menjadi pengemas Fedora yang disponsori.

  2. Anda harus bersedia menjadi rekan pemelihara untuk paket yang dimaksud. Ini tidak boleh digunakan untuk kontribusi sesaat (drive-by contributions).

Minggu 0

  1. Ajukan bug baru terhadap paket tersebut di Bugzilla, dengan permintaan tarik yang ditautkan jika berlaku (ini mungkin tidak diperlukan jika Anda meminta cabang EPEL dan cabang yang ada dapat dibangun dengan baik, dalam hal ini harap berikan bukti misalnya hasil pembangunan scratch).

Minggu 1

  1. Setelah 7 hari, ping bug tersebut, beri status NEEDINFO pada orang yang ditugaskan (assignee) dan mintalah tanggapan.

Minggu 3

  1. Setelah 14 hari berikutnya tanpa tindakan, ajukan tiket releng yang meminta izin komit untuk menjadi rekan pemelihara paket. Pemelihara yang tidak responsif dan semua pemelihara yang ada harus disebutkan dengan @ dalam tiket tersebut. Jika permintaan tersebut bertujuan untuk cabang EPEL, nyatakan juga bahwa Anda bersedia dijadikan sebagai penerima tugas (assignee) bugzilla EPEL default.

    Tiket releng ini harus disetujui dengan suara `+1` oleh setidaknya satu anggota FESCo
(selain pembuat permintaan, jika juga merupakan anggota FESCo).
Segera setelah hal itu terjadi dan selama hanya ada suara `+1`,
tiket dianggap disetujui.
Jika ada suara lain (`0` atau `-1`),
FESCo akan mengikuti kebijakan pemungutan suara yang biasa untuk menyetujui atau menolak tiket tersebut.

Want to help? Learn how to contribute to Fedora Docs ›