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 maintainer tidak menjawab bug yang ditujukan kepadanya, tidak menanggapi permintaan rebuild, pull request di src.fedoraproject.org, email, memiliki alamat email yang tidak valid, akun Bugzilla yang dinonaktifkan di FAS, atau hal serupa, langkah-langkah berikut harus diikuti:

Minggu 0

  1. Periksa apakah maintainer yang tidak responsif ada di vacation. Untuk melihat apakah maintainer baru-baru ini aktif di Fedora, fedora-active-user dapat digunakan.

  2. Ajukan bug baru terhadap paket di Bugzilla yang meminta maintainer untuk merespons dengan menggunakan templat yang sesuai dan isi semua kolomnya (templat untuk maintainer paket yang tidak responsif atau maintainer container yang tidak responsif. Jika alamat email maintainer atau akun Bugzilla-nya tidak aktif, langkah ini dapat dilewati.

  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. After 7 days, submit a FESCo issue with the bug link and mailing list post link. State if you are a packager and want to take over the nonresponsive maintainer’s package or packages. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. This ticket MAY be filed at the same time as the devel post is sent in which case the FESCo voting period will start 7 days after the devel post was sent.

  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 email tidak valid

Bugzilla menggunakan alamat email di Fedora Account System untuk mengirim pesan kepada maintainer paket. Jika diketahui bahwa alamat email ini tidak lagi menuju ke maintainer paket, masalah pada alamat email tersebut harus dicatat dalam kiriman mailing list dan tiket FESCo. Dalam kasus ini, kewajiban untuk mengajukan bug Bugzilla tentang maintainer yang tidak responsif ditiadakan, tetapi kewajiban untuk mengirim kiriman ke milis devel tetap berlaku.

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

  1. Email ke alamat tersebut terpental dengan kesalahan pengguna tidak valid (seperti Recipient address rejected: User unknown in local recipient table).

  2. Penyedia atau perusahaan yang terkait dengan alamat tersebut menyatakan bahwa alamat itu tidak valid.

  3. Email ke alamat tersebut terpental karena alasan lain (untuk membedakannya dari pantulan sementara seperti kotak surat penuh, hal ini harus berlangsung selama periode 7 hari).

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 NEEDINFO pada assignee, dan minta tanggapan.

Minggu 3

  1. Setelah 14 hari berikutnya tanpa tindakan, kirim tiket releng untuk meminta izin commit agar dapat menjadi co-maintainer paket tersebut. Maintainer yang tidak responsif dan semua maintainer yang ada harus di-@-mention dalam tiket. Jika permintaan tersebut untuk branch EPEL, nyatakan juga bahwa Anda bersedia dijadikan assignee Bugzilla EPEL default.

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

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