Siapa yang Diizinkan untuk Mengubah Paket Tertentu

Dengan tata letak Git saat ini, setiap anggota grup provenpackager dapat memodifikasi sebagian besar paket. Sebagai pengecualian, beberapa paket tertentu dapat ditutup aksesnya bagi provenpackagers, setelah mendapat persetujuan dari FESCo.

Ringkasan

Biasanya, pemelihara yang tercantum sebagai pemelihara utama dalam repositori dist-git suatu paket adalah satu-satunya yang dapat memodifikasi paket tersebut atau memberikan izin kepada pihak lain (misalnya dengan menambahkan mereka sebagai rekan pemelihara) untuk melakukan commit dan build perubahan pada paket itu. Bugzilla atau permintaan penarikan (pull request) di repositori biasanya merupakan cara terbaik untuk menghubungi pemelihara paket atau mengirimkan patch dan saran, karena keduanya bersifat netral dan dapat dilacak; namun, mencoba menghubungi mereka sekali atau dua kali melalui IRC atau email langsung juga bisa menjadi ide yang baik.

Namun, ada pengecualian tertentu di mana para pemelihara harus menerima bahwa pembuat paket lain dapat memodifikasi paket yang menjadi tanggung jawab mereka. Pengecualian tersebut dijelaskan secara rinci di bawah ini. Secara umum, dalam kasus berikut, provenpackagers diperbolehkan untuk memperbaiki masalah pada paket milik orang lain:

  • seorang pembuat paket tidak memperbaiki bug penting tepat waktu

  • ada masalah yang diketahui dan dapat berdampak buruk pada seluruh Proyek atau banyak pengguna repo/paket tertentu

  • perubahan yang dilakukan bersifat kecil atau dianggap sebagai pembersihan umum terhadap banyak paket

  • perubahan merupakan bagian dari Tujuan Fedora, dengan rencana spesifik yang telah disetujui oleh FESCo

Rincian

Bagian ini berusaha menjelaskan aturan di atas secara lebih rinci. Bagian ini tidak akan dapat mencakup semua situasi yang mungkin muncul di Fedora, tetapi seharusnya dapat memberikan gambaran umum tentang bagaimana menerapkan aturan tersebut.

Masalah yang tidak tertangani

Pembuat paket harus memantau paket yang menjadi tanggung jawab mereka. Artinya:

  • menanggapi bug yang dilaporkan di Bugzilla, terutama dengan cepat jika masalah tersebut serius seperti masalah keamanan

  • memperbaiki masalah tanpa menunggu peringatan langsung jika disebutkan dalam laporan masalah — termasuk di dalamnya:

    • memperbaiki masalah EVR ketika disebutkan dalam laporan masalah (misalnya jalur pembaruan yang terputus)

    • memperbaiki masalah ketergantungan (termasuk yang ada di repositori devel) — skrip mengirimkan laporan masalah kepada pemelihara dan juga ke milis

    • berpartisipasi dalam rekonstruksi massal (mass-rebuilds) dan memperbaiki bug Gagal Dibangun dari Sumber

  • memperbarui ke versi baru perangkat lunak saat tersedia dari hulu, mengikuti kebijakan pembaruan

Jika pembuat paket tidak memantau hal-hal tersebut, maka pembuat paket berpengalaman lainnya bebas memperbaiki masalah untuk mereka. Tidak mungkin menentukan jangka waktu pasti kapan kontributor harus turun tangan untuk memperbaiki masalah, karena hal itu tergantung pada seberapa parah masalah yang harus diperbaiki. Namun, berikut beberapa contoh:

  • masalah keamanan:

    • Masalah penting harus diperbaiki sesegera mungkin — menunggu satu hari untuk pemelihara merespons dan kemudian turun tangan untuk memperbaiki masalah yang telah dilaporkan kepada mereka dianggap sudah lebih dari cukup; bahkan mungkin ada situasi di mana masalah perlu diperbaiki lebih cepat

    • masalah yang tidak terlalu penting juga harus ditangani dengan cepat — menunggu selama 2–7 hari (tergantung seberapa serius masalahnya) dianggap cukup

  • bug yang perlu ditangani dengan cara serupa seperti masalah keamanan:

    • Masalah penting (misalnya kerusakan data bagi pengguna) harus diperbaiki sesegera mungkin — menunggu satu hari juga dianggap sudah cukup di sini

    • bug yang merugikan tetapi tidak terlalu parah bagi pengguna — menunggu selama 2–14 hari (tergantung tingkat keparahan masalah) dianggap cukup

    • bug yang mengganggu tetapi tidak merugikan secara signifikan — menunggu selama 21 hari dianggap cukup

Beberapa catatan:

  • Jika seorang pembuat paket akan offline untuk jangka waktu yang cukup lama (misalnya lima hari atau lebih) karena liburan, perjalanan, atau alasan lainnya, mereka dapat mengumumkannya di kalender liburan. Dalam kasus ini, orang lain akan tahu untuk tidak mengharapkan jawaban sebelum pembuat paket kembali, dan dapat segera melanjutkan untuk memperbaiki masalah (misalnya jika perlu menerapkan Perbaikan Keamanan).

  • "Unhandled" benar-benar berarti sama sekali tidak tertangani — jika pemelihara pernah merespons sekali dalam laporan bug, tetapi kemudian tidak memberikan tanggapan lagi, coba hubungi mereka kembali; mungkin saja mereka hanya lupa tentang bug tersebut. Atau mungkin ada alasan yang baik mengapa mereka belum melakukan commit atas perbaikan yang disediakan.

  • Jika kamu melakukan commit perubahan pada paket orang lain, tunggu beberapa jam jika memungkinkan (biasanya 24 atau 48 jam) sebelum benar-benar membangun paket yang diperbarui, selama masalahnya bukan sesuatu yang serius yang perlu segera diperbaiki (seperti masalah keamanan, dan sejenisnya). Ini memberikan waktu bagi pemelihara untuk merespons.

  • Pembuat paket berpengalaman sebaiknya membatasi perubahan mereka pada paket orang lain hanya untuk hal-hal yang telah disepakati bersama. Artinya, jangan memperbaiki hal-hal yang sifatnya kontroversial atau hanya masalah gaya.

Perubahan kecil, umum, atau pembersihan

Terkadang ada situasi di mana jauh lebih mudah memperbaiki sesuatu langsung di Git daripada melalui Bugzilla dan pemelihara resmi. Begitu mudahnya hingga jalur ini sebaiknya tetap dibiarkan terbuka. Namun, situasi ini seharusnya jarang terjadi. Berikut beberapa contoh di mana melewati pemelihara resmi dianggap dapat diterima:

  • dukungan untuk arsitektur baru — yang sering kali membutuhkan banyak paket yang perlu disesuaikan atau ditambal, dan pembuat paket sering kali bahkan tidak dapat mengujinya sendiri. Memasukkan semua modifikasi tersebut melalui Bugzilla sangat merepotkan, sehingga hal-hal seperti ini dapat langsung diperbaiki di rawhide tanpa menghubungi masing-masing pemelihara jika upaya umum tersebut sudah diumumkan sebelumnya. Sebuah SIG sebaiknya menangani hal ini dan melanjutkan operasi normal setelah upaya porting awal selesai.

  • perbaikan kecil atau penyesuaian untuk pedoman pengemasan baru atau yang diperbarui dapat dilakukan langsung di Git setelah diumumkan beberapa hari sebelumnya.

  • pembangunan ulang massal.

Perubahan untuk Tujuan Fedora

Terkadang, kita mungkin ingin melakukan perubahan besar yang melampaui sekadar pembersihan, guna mendukung Tujuan Fedora yang telah disetujui oleh Dewan. Perubahan semacam ini akan lebih mudah dilakukan secara terkoordinasi daripada individu. Dalam situasi ini, FESCo akan membahas sebuah rencana, termasuk lingkup perubahan, dan mengkomunikasikannya melalui milis devel.

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