Kebijakan pembaruan

Fondasi "Pertama" Fedora

Fedora Linux adalah distribusi yang bergerak cepat secara desain. Hal ini diwujudkan dalam fondasi Pertama: kami menyediakan perangkat lunak bebas terbaru yang stabil, andal, berguna, dan kuat.

Komunitas kami mengharapkan Fedora untuk dengan cepat mengintegrasikan versi perangkat lunak baru dari berbagai sumber hulu ke dalam repositori kami, tetapi dengan gangguan seminimal mungkin dan dengan cara yang selaras dengan paket lainnya. Keseimbangan ini adalah inti dari peran seorang pemelihara paket, dan dokumen ini menjelaskan kebijakan kami untuk bekerja sama menciptakan pengalaman terbaik bagi semua pihak.

Kami memberikan kepercayaan besar kepada setiap pemelihara paket individu dalam mengelola dan memperbarui paket mereka, sesuai dengan Pedoman Pengemasan Fedora dan kebijakan yang dijelaskan di sini. Namun, harap diingat bahwa ini adalah usaha kolektif. Kami menghargai, mengapresiasi, dan merayakan kerja keras setiap pemelihara terhadap paket mereka, dan kami juga mendorong kepemeliharaan bersama serta kolaborasi untuk meningkatkan pengemasan di seluruh koleksi Fedora.

Tentang kebijakan ini

Fedora memiliki kebijakan yang berbeda untuk setiap cabang rilisnya. Dokumen ini menjelaskan kepada para pemelihara jenis pembaruan seperti apa yang perlu dibuat untuk paket di masing-masing cabang Fedora yang ada. Jika ada pertanyaan atau perlu klarifikasi, harap buat tiket FESCo atau diskusikan di daftar devel. Secara umum, rilis berjalan dari yang kurang konservatif (Rawhide) hingga yang lebih konservatif (rilis stabil tertua yang masih didukung). Dokumen ini berupaya menjelaskan kapan dan jenis pembaruan seperti apa yang sebaiknya dikirimkan oleh pemelihara kepada pengguna Fedora di berbagai cabangnya. Visi pembaruan rilis stabil dari Dewan Fedora mencakup pembahasan dan filosofi tingkat tinggi, sedangkan dokumen ini lebih berfungsi sebagai panduan praktis. Lihat juga Panduan Pembaruan Paket untuk langkah teknis dalam mendorong pembaruan. Siklus Rilis Fedora menyediakan gambaran lebih rinci tentang proses pengembangan.

Persyaratan umum pembaruan untuk semua rilis Fedora

Beberapa kriteria berlaku untuk setiap pembaruan di cabang/rilis Fedora mana pun:

Memperbarui paket yang saling bergantung

Ketika satu paket yang diperbarui memerlukan satu atau lebih paket lainnya, paket-paket tersebut harus diajukan bersama sebagai satu pembaruan tunggal. Misalnya, jika paket A bergantung pada paket B dan C, dan Anda ingin memperbarui A ke versi baru yang memerlukan versi baru dari B dan C, Anda harus mengirimkan satu pembaruan yang berisi versi terbaru dari A, B, dan C. Mengajukan tiga pembaruan terpisah adalah ide yang buruk, karena jika pembaruan untuk paket A dipromosikan menjadi stabil sebelum B dan C, hal itu akan menimbulkan masalah ketergantungan. Informasi tentang cara mengajukan pembaruan multi-paket tersedia di Panduan Pembaruan Paket, dan informasi tentang penggunaan side-tag untuk beberapa pembaruan terdapat di Rawhide Gating/multi-builds.

Pembaruan yang dapat digunakan

Pembaruan Bodhi hanya boleh dibuat untuk build yang layak untuk dipromosikan menjadi stabil. Pemelihara sebaiknya tidak menggunakan status pengujian Bodhi untuk menguji pembaruan yang tidak pernah dimaksudkan untuk dirilis stabil. Jenis pengujian ini sebaiknya dilakukan di Copr atau repositori publik terpisah lainnya. Konsultasikan dengan tim QA untuk bantuan pengujian lebih lanjut.

Rawhide

Rawhide adalah pohon pengembangan yang selalu bergulir (rolling). Pembaruan paket yang dibuat untuk Rawhide dikomposisi setiap hari dan didistribusikan ke seluruh pengguna. Build baru terhadap pohon ini juga ditambahkan ke build root (yaitu, paket lain dibangun darinya). Pohon ini dimaksudkan untuk memenuhi Kriteria Rilis Dasar bagi setiap hasil komposisi yang berhasil, agar para pemelihara dapat mengintegrasikan perubahan mereka bersama semua pihak lainnya.

Repositori yang tersedia: rawhide

Sejak perubahan Gating Rawhide Packages diperkenalkan, pembaruan paket di Fedora Rawhide harus lulus verifikasi sebelum dapat masuk ke dalam repositori Rawhide. Hal ini diterapkan sebagai pemeriksaan pada pembaruan Bodhi, yang memverifikasi bahwa pembaruan tersebut memenuhi kebijakan Gating. Lihat Rawhide Gating/Single Builds dan Rawhide Gating/Multi Builds untuk detailnya.

Saat ini kebijakan gating bawaan masih kosong, sehingga pembaruan Rawhide dapat melewati pemeriksaan tanpa memedulikan hasil pengujian. Pemelihara paket dapat memilih untuk ikut serta dalam gating suatu paket dengan menyiapkan kebijakan gating individual, lihat Cara Mengaktifkan Gating.

Segera setelah sebuah build selesai, pembaruan Bodhi akan dibuat secara otomatis. Pembaruan ini digunakan untuk mengumpulkan hasil pengujian. Jika pengujian gating berhasil, pembaruan tersebut akan ditandai sebagai stabil dalam beberapa menit, didorong menjadi stabil, dan akan dimasukkan ke dalam compose malam berikutnya.

Untuk pembaruan pada paket Rawhide, pemelihara WAJIB:

  • tidak mendorong build yang diketahui rusak (misalnya merusak set paket buildroot bawaan, dan sebagainya). Hal ini akan menambah pekerjaan bagi pemelihara lain yang mencoba mengintegrasikan perubahan mereka.

  • Ketika pembaruan yang diusulkan mengandung perubahan ABI atau API: beri tahu satu minggu sebelumnya baik melalui daftar devel maupun langsung kepada para pemelihara (menggunakan alias packagename-maintainers@fedoraproject.org) dari paket-paket yang bergantung pada paket Anda, agar mereka dapat melakukan pembangunan ulang atau Anda dapat menawarkan untuk melakukannya bagi mereka.

  • Gunakan side-tag ketika menangani pembangunan massal dari banyak paket, agar semuanya dapat dirilis secara bersamaan. Lihat Rawhide Gating/Multi Builds.

  • Silakan mendorong versi terbaru dari paket selama tidak menyebabkan kerusakan. Namun perlu diingat waktu ketika rilis Fedora berikutnya akan dicabangkan (branched), dan pastikan bahwa akan ada rilis yang cukup stabil tepat waktu untuk rilis Fedora berikutnya. Jika tidak, Anda mungkin harus kembali ke versi lama yang stabil setelah proses branching, yang dapat melibatkan penggunaan epoch dan ketidaknyamanan lainnya.

  • Setelah suatu paket telah dimasukkan ke dalam komposisi (compose) dan proses tersebut selesai serta disinkronkan ke cermin utama, biasanya paket tersebut tidak akan dihapus (untagged). Hal ini diperlukan agar pihak lain dapat bergantung pada build tersebut setelah menjadi terlihat. Dalam kasus luar biasa, tim release engineering dapat menghapus tag paket.

  • Jika telah disetujui oleh FESCo, dorong versi pre-release dari paket tingkat rendah. FESCo menyetujui beberapa paket, termasuk (namun tidak terbatas pada) glibc dan gcc, untuk menyediakan versi pra-rilis di sini. Manfaat dari pengujian awal di dunia nyata dan kolaborasi dengan proyek hulu pada paket-paket kunci ini jauh lebih besar dibandingkan risiko yang mungkin ditimbulkan.

Alur pembaruan

Rilis bercabang (Branched release)

Sebuah rilis Branched ada untuk sebagian dari siklus pengembangan. Rilis ini dimulai sebagai turunan dari Rawhide dan akhirnya menjadi rilis stabil berikutnya. Semua komposisi bercabang yang berhasil harus memenuhi Kriteria Rilis Dasar.

Rilis bercabang menggunakan sistem umpan balik pembaruan (Bodhi): awalnya sama seperti Rawhide (pembaruan dibuat secara otomatis ketika build selesai, pengujian dijalankan dan build secara otomatis dimasukkan ke komposisi berikutnya), namun setelah Aktivasi Updates-testing mereka beralih ke sistem yang sama dengan rilis stabil (pemelihara harus membuat pembaruan dan mengajukannya untuk pengujian, dan sebagainya).

Ada beberapa fase yang dilalui oleh rilis bercabang yang memengaruhi jenis pembaruan yang dapat dan seharusnya dilakukan. Secara umum, pemelihara harus mengingat bahwa cabang ini sedang dalam proses stabilisasi untuk rilis berikutnya, sehingga perubahan harus dilakukan dengan hati-hati, pertimbangan matang, dan mengarah pada stabilitas.

Setelah proses branching, akan ada tiga masa pembekuan: Pembekuan pasca-branch (Post-branch Freeze), Pembekuan Beta (Beta Freeze), dan Pembekuan Final (Final Freeze).

Pembekuan pasca-branch (Post-branch Freeze)

Setelah rilis baru bercabang dari Rawhide, alur pembaruan melalui Bodhi akan dihentikan hingga ada komposisi bercabang yang berhasil. Periode ini biasanya berlangsung hanya beberapa hari. Tim release engineering dapat mengizinkan beberapa pembaruan untuk menjadi stabil agar komposisi dapat selesai, tetapi selain itu semua pembaruan akan dijeda hingga komposisi bercabang awal ini selesai. Hal ini dilakukan untuk memastikan bahwa kita memiliki komposisi dasar yang dapat digunakan sebelum menangani masalah yang mungkin timbul dari pembaruan baru.

Sebelum Aktivasi Updates-testing

Untuk waktu yang singkat setelah proses branching tetapi sebelum Pembekuan Beta (Beta Freeze), rilis bercabang berfungsi seperti Rawhide: build yang dikirimkan oleh pemelihara dianggap stabil setelah melewati pengujian gating melalui pembaruan Bodhi, dan dikirim langsung ke repositori fedora pada komposisi malam berikutnya. Tidak ada batasan tambahan selain yang berlaku untuk Rawhide pada tahap ini, tetapi mulai dari titik ini pemelihara SEHARUSNYA mulai memikirkan proses stabilisasi dan memastikan paket mereka berada dalam kondisi baik jauh sebelum rilis stabil.

Repositori yang tersedia: fedora

Aktivasi Updates-testing

Pada tahap ini, sistem pembaruan Bodhi diubah agar rilis bercabang berperilaku seperti rilis stabil (lihat di bawah) alih-alih seperti Rawhide. Mulai saat ini, para pemelihara harus membuat pembaruan terlebih dahulu sebelum paket menjadi tersedia bagi pengguna, dan pembaruan harus melewati updates-testing untuk memungkinkan umpan balik. Pembaruan dipindahkan dari repositori updates-testing ke repositori fedora setelah persyaratan karma yang sesuai terpenuhi. Bodhi menetapkan nilai bawaan yang wajar dan menegakkan persyaratan minimum untuk pembaruan. Persyaratan Karma untuk pembaruan dijelaskan di bawah.

Repositori yang tersedia: fedora, updates-testing

Pemelihara SEHARUSNYA:

  • Menghindari perubahan ABI/API bila memungkinkan. Jika tidak dapat dihindari, gunakan side-tag untuk membangun ulang paket.

  • Menghindari perubahan apa pun yang dapat merusak komposisi Live media, media instalasi, atau pengujian.

  • Memasukkan semua paket yang diperlukan untuk Changes yang telah direncanakan untuk rilis tersebut.

Pembekuan Beta (Beta Freeze)

Pembekuan ini dijadwalkan berlangsung selama tiga minggu menjelang tanggal rilis, tetapi tetap berlaku sampai rilis ditandatangani, bahkan jika terjadi penundaan. Selama masa pembekuan, build tidak akan ditandai sebagai stabil dan dipindahkan dari updates-testing ke fedora (dan karenanya tidak akan dimasukkan ke dalam komposisi rilis milestone) kecuali jika disetujui berdasarkan proses bug blocker atau proses pengecualian pembekuan oleh tim QA Fedora. Setelah rilis beta dibuat, pembekuan akan dicabut. Halaman Milestone freezes menyediakan detail lebih lanjut dan menjadi referensi utama jika terjadi perbedaan.

Setelah Pembekuan Beta dimulai, kita berusaha menstabilkan versi utama perangkat lunak yang akan disertakan dalam rilis akhir sistem operasi. Pembaruan besar masih bisa ditoleransi, tetapi merusak sistem bagi penguji awal harus dihindari jika memungkinkan.

Selama periode ini:

  • Semua pembaruan yang dimasukkan ke dalam rilis WAJIB memperbaiki bug yang diterima sebagai blocker atau permintaan pengecualian pembekuan.

  • Semua pembaruan tetap masuk ke updates-testing.

Repositori yang tersedia: fedora, updates-testing

Dari Beta ke Pembekuan Final (Beta to Final Freeze)

Ini adalah waktu antara rilis Beta dan Pembekuan Final (Final Freeze). Pohon cabang sekarang harus distabilkan dan dipersiapkan untuk rilis akhir. Perubahan besar harus dihindari selama periode ini. Ingatlah bahwa dalam sebagian besar kasus, keadaan paket Anda di repositori stabil fedora pada saat Pembekuan Final adalah keadaan yang akan dikirimkan dalam rilis final.

Repositori yang tersedia: fedora, updates-testing

Pembekuan Final (Final Freeze)

Pembekuan ini menghasilkan pembuatan rilis akhir. Prosesnya serupa dengan Pembekuan Beta (Beta Freeze) yang dijelaskan di atas dan mengikuti aturan pembaruan yang sama.

Repositori updates diaktifkan pada suatu titik selama periode ini, dan paket selain perbaikan freeze exception atau blocker akan diantrekan untuk apa yang disebut pembaruan "hari nol" (zero day updates), artinya pembaruan tersebut akan tersedia di repositori updates pada saat rilis (hari pertama rilis).

Repositori yang tersedia: fedora, updates, updates-testing

Selama periode ini:

  • Semua pembaruan yang dimasukkan ke dalam rilis WAJIB memperbaiki bug yang diterima sebagai blocker atau permintaan pengecualian pembekuan.

  • Semua pembaruan masih dikirim ke updates-testing.

  • Setelah repositori updates tersedia, build yang ditandai sebagai stabil akan masuk ke repositori tersebut, bukan ke fedora.

Rilis Stabil

Filosofi

Rilis dari distribusi Fedora mirip dengan rilis dari paket individu yang menyusunnya. Nomor versi utama mencerminkan seperangkat fitur dan fungsi yang kurang lebih stabil. Oleh karena itu, kita sebaiknya menghindari pembaruan besar terhadap paket dalam rilis stabil. Pembaruan sebaiknya difokuskan untuk memperbaiki bug, bukan memperkenalkan fitur baru, terutama jika fitur tersebut secara signifikan memengaruhi pengalaman pengguna atau pengembang. Laju pembaruan untuk setiap rilis seharusnya menurun seiring waktu, mendekati nol menjelang akhir masa dukungan; karena pembaruan terutama berupa perbaikan bug, kebutuhan terhadapnya akan semakin berkurang seiring waktu.

Hal ini berarti bahwa rilis stabil tidak akan selalu mengikuti kode hulu terbaru untuk semua paket. Untuk itu, kita memiliki Rawhide.

Pembaruan harus dipertimbangkan secara hati-hati dengan mempertimbangkan ketergantungannya. Sebagai contoh, pembaruan yang membutuhkan (atau menyediakan) ABI Python baru hampir pasti tidak akan diizinkan. Perubahan ABI secara umum sangat tidak disarankan karena dapat memaksa pengguna untuk melakukan pembaruan paket dalam jumlah besar dan menyulitkan pengembang pihak ketiga. Selain itu, pembaruan yang mengonversi sumber daya atau konfigurasi dalam satu arah (misalnya dari yang lama → yang baru) harus dilakukan dengan sangat hati-hati, karena akan sulit membatalkan pembaruan yang membuat perubahan semacam itu.

Sebisa mungkin, pemelihara paket harus bekerja sama dengan proyek hulu untuk membuat rilis cabang stabil atau tambalan umum bagi rilis lama, terutama ketika pembaruan membutuhkan rantai ketergantungan dalam jumlah besar.

Repositori yang tersedia: fedora updates updates-testing

Selama periode ini:

Pengecualian

Beberapa jenis perangkat lunak tidak akan sesuai dengan pedoman ini. Jika paket Anda tidak termasuk dalam salah satu kategori di bawah ini, tetapi menurut Anda seharusnya diizinkan untuk diperbarui lebih cepat, ajukan kelas pengecualian baru ke FESCo dan/atau minta pengecualian untuk kasus pembaruan Anda secara spesifik.

Perlu dicatat bahwa dialog ini harus dibuka sebelum Anda membangun atau mendorong pembaruan. Jika muncul masalah di tengah proses pembaruan yang sedang berlangsung, pastikan Anda menonaktifkan fitur autokarma pushes — hal ini dapat dilakukan saat pembaruan masih tertunda di Bodhi.

Hal-hal berikut akan dipertimbangkan dalam permintaan pengecualian.

Hal-hal yang meningkatkan kemungkinan permintaan disetujui:

  • Paket tersebut merupakan simpul “leaf”. Tidak ada paket lain yang bergantung padanya.

  • Pembaruan memperbaiki masalah keamanan yang memengaruhi banyak pengguna.

  • Pembaruan tidak mengubah ABI/API dan tidak ada paket lain yang perlu dibangun ulang terhadap versi baru tersebut.

  • Pembaruan memperbaiki bug serius yang dialami banyak pengguna Fedora.

Hal-hal yang menurunkan kemungkinan permintaan disetujui:

  • Pembaruan mengonversi basis data atau sumber daya secara satu arah ke format baru.

  • Pembaruan memerlukan intervensi admin agar layanan tetap berfungsi (misalnya perubahan format file konfigurasi, dan sebagainya).

  • Pembaruan menyebabkan perubahan perilaku (misalnya sesuatu yang sebelumnya ditolak menjadi diizinkan, dan sebagainya).

  • Pembaruan mengubah antarmuka pengguna (UI) yang dilihat oleh pengguna akhir (memindahkan menu atau tombol, mengubah nama opsi di baris perintah)

  • Pembaruan memperbaiki bug yang tidak pernah dilaporkan oleh pengguna Fedora atau yang tidak memengaruhi banyak pengguna Fedora (misalnya perbaikan untuk platform atau konfigurasi lain).

Daftar pengecualian

Paket-paket berikut telah diberikan pengecualian karena alasan-alasan berikut:

KDE

Lihat Kebijakan pembaruan KDE untuk informasi lebih lanjut.

LXQt

SIG LXQt diberikan pengecualian permanen untuk rangkaian paket Desktop LXQt. (Pengecualian ini tidak berlaku untuk paket di luar proyek LXQt.)

Paket kernel

  • Keterbatasan waktu dan sumber daya menghambat para pemelihara kernel untuk melakukan backport semua perbaikan bug, perbaikan keamanan, dan dukungan perangkat keras baru yang diperlukan untuk mempertahankan kernel lama yang sudah tidak didukung.

  • Selain itu, beberapa kernel dapat diinstal/dijalankan bersamaan, sehingga pengguna dapat mem-boot kernel lama jika kernel baru tidak berfungsi, serta memberi waktu bagi pemelihara kernel untuk memperbaiki bug kritis pada kernel baru di rilis stabil lama.

Paket -devel Rust

Pengecualian ini mencakup semua paket -devel Rust, yaitu RPM yang berisi sumber kode Rust. Paket-paket ini digunakan untuk membangun biner Rust yang dikemas dan tidak digunakan secara langsung oleh pengguna.

Paket lainnya

Paket-paket berikut diizinkan untuk diperbarui pada rilis stabil:

  • Penampil dokumen zathura dan pustaka girara (FESCo #1255),

  • Aplikasi kontrol printer 3D prusa-slicer dan tumpukan Cura (CuraEngine dan paket lainnya) (FESCo #2652),

  • Alat pemformat kode Python python-black (FESCo #2652),

  • Alat pemeriksa kode Python ruff (FESCo #3197),

  • Eksekutor pengujian Python python-tox (FESCo #2652),

  • Klien HTTP baris perintah httpie (FESCo #2652),

  • Klien Desktop ownCloud owncloud-client (FESCo #2652),

  • Perangkat lunak EDA KiCad kicad, kicad-packages3d, dan kicad-doc (FESCo #2762),

  • Pustaka pengurai HTTP llhttp (FESCo #3115),

  • Alat otomatis SSL Let’s Encrypt certbot (FESCo #3124),

  • Manajer paket dan proyek Python uv (FESCo #3262),

  • Alat ruang pengguna Python untuk kerangka kerja DAMON kernel python-damo (FESCo #3389),

  • Plugin Docker docker-compose, docker-buildx, dan docker-buildkit (FESCo #3394).

  • Editor gambar gimp (FESCo #3511).

Perbaikan keamanan

Jika proyek hulu tidak menyediakan perbaikan keamanan untuk rilis tertentu, dan jika melakukan backport perbaikan tersebut tidak memungkinkan, maka pemelihara paket WAJIB membuka tiket FESCo untuk mendapatkan persetujuan guna melakukan pembaruan versi ke versi yang masih didukung oleh hulu.

Pemelihara paket WAJIB:

  • Menghindari pembaruan versi utama, kerusakan ABI, atau perubahan API jika memungkinkan

  • Menghindari perubahan pada pengalaman pengguna atau pengembang jika memungkinkan

FESCo akan meninjau tiket tersebut secara tepat waktu dan memberikan panduan tentang bagaimana pemelihara paket harus melanjutkan. Beberapa hal umum yang akan mengurangi kemungkinan FESCo menyetujui permintaan pembaruan versi tercantum di bawah ini. Namun perlu diingat, daftar ini tidak bersifat menyeluruh.

  • Pembaruan memerlukan intervensi pengguna atau administrator agar tetap berfungsi

  • Pembaruan memerlukan file konfigurasi, basis data, atau sumber daya lain untuk dikonversi ke format baru

  • Pembaruan menyebabkan perubahan kebijakan atau perilaku (misalnya sesuatu yang sebelumnya ditolak kini diizinkan, dan sebagainya)

  • Pembaruan mengubah cara pengguna berinteraksi dengan antarmuka pengguna (misalnya memindahkan menu atau tombol ke lokasi baru, mengubah nama argumen baris perintah, dan sebagainya)

  • Prebasing hanya menangani masalah yang kemungkinan hanya memengaruhi sejumlah kecil pengguna Fedora secara subyektif

Paket dengan Pengecualian yang Diberikan

  • kernel

Interoperabilitas

Jika suatu paket terutama berfungsi untuk berinteraksi dengan perangkat keras atau protokol jaringan, dan antarmuka tersebut berubah, maka paket dapat diperbarui (rebase) jika perlu. Ini termasuk permainan jaringan, protokol IM, pemutar musik perangkat keras, ponsel, dan sebagainya. Paket-paket ini juga dapat diperbarui untuk menambahkan dukungan bagi perangkat atau format baru dengan cara yang tetap kompatibel.

Contoh jenis paket ini:

Paket basis data

Paket seperti pemindai virus dan penyaring spam biasanya memiliki dua komponen: mesin aturan (rules engine) dan basis data. Basis data diharapkan diperbarui secara sering (terkadang tidak melalui mekanisme pembaruan sistem operasi normal), tetapi mesin aturan biasanya cukup statis. Namun, jika basis data yang dipelihara berubah dan membutuhkan versi baru dari mesin aturan, maka paket tersebut dapat menjadi kandidat untuk diperbarui (rebase).

Contoh jenis paket ini:

Contoh

  • Mozilla merilis Firefox 4.0.1 dengan perbaikan keamanan. Fedora 12 menggunakan versi 3.0.7, dan meskipun bug yang sama ada di sana, perbaikan di 4.0.1 tidak dapat diterapkan karena bagian browser tersebut telah sepenuhnya ditulis ulang. Pembaruan ke 4.0.1 diperbolehkan karena ini merupakan perbaikan keamanan.

  • automake merilis versi baru yang mengubah beberapa kondisi warning menjadi kesalahan (error). Hal ini akan merusak proses pembangunan untuk paket yang sudah ada, sehingga tidak diizinkan.

  • AOL mengubah protokol pesan instan mereka dengan cara yang memerlukan pembaruan libpurple. Satu-satunya versi libpurple dari hulu yang mendukung protokol baru tersebut menyebabkan kerusakan ABI dibanding versi yang ada di rilis Fedora saat ini. Pembaruan versi diperbolehkan karena merupakan kebutuhan interoperabilitas.

  • Abiword merilis versi baru yang menambahkan kompatibilitas dengan dokumen WordStar 4.0, serta memperbarui seluruh antarmuka pengguna menjadi menggunakan menu melingkar (pie menus). Ini merupakan peningkatan fitur dengan perubahan besar pada pengalaman pengguna dan tidak akan diizinkan.

  • WebKit memerlukan pembaruan untuk menyelesaikan masalah keamanan. Hal ini mengharuskan Midori diperbarui ke versi dengan beberapa perubahan kecil pada tata letak menu. Kasus ini akan dinilai berdasarkan seberapa signifikan perubahan tersebut (menghapus menu “File” akan dianggap buruk, tetapi memindahkan menu konfigurasi plugin dapat diterima).

  • Firefox merilis pembaruan yang hanya berisi perubahan untuk platform lain. Pembaruan ini dapat dikirim ke Rawhide (untuk tetap mengikuti versi terbaru), tetapi tidak boleh dikirim ke rilis stabil, karena tidak memberi manfaat apa pun bagi pengguna kita dan hanya membuang sumber daya untuk membangun, memperbarui, mencerminkan, dan mengunduh bagi pengguna.

  • Terminal gagal dibangun dari sumber saat diuji dalam pembangunan massal (mass rebuild). Paket yang diperbarui sebaiknya dikirim ke Rawhide. Perbaikan untuk rilis stabil sebaiknya diuji dan bahkan dikomit, tetapi kecuali ada masalah dengan build yang sudah ada di rilis stabil, tidak perlu mengeluarkan pembaruan. Pembaruan ini tidak mengubah fungsi paket yang terlihat oleh pengguna.

  • Hulu KDE merilis versi utama baru, dan pada saat yang sama menghentikan dukungan untuk rilis lama yang ada di Fedora N dan Fedora N-1. Rilis ini mencakup banyak perbaikan bug, bersamaan dengan peningkatan dan perbaikan keamanan. Pengecualian untuk jenis pembaruan ini harus mempertimbangkan: kemampuan untuk backport perbaikan besar/perbaikan keamanan, jenis dan jumlah bug yang diperbaiki, kemampuan untuk tidak memperbarui bagian lain dari Fedora untuk pembaruan ini (misalnya, menghindari perubahan ABI pada Qt atau pustaka dasar lainnya), jumlah pengujian, serta perubahan yang terlihat bagi pengguna akhir. Pengecualian seperti ini akan dipertimbangkan per kasus berdasarkan faktor-faktor tersebut.

Persyaratan Karma

Bagian ini menjelaskan persyaratan bagi sebuah pembaruan sebelum dapat dipindahkan dari updates-testing ke fedora atau updates. Persyaratan ini didasarkan pada (jumlah dari) poin karma Bodhi dan jumlah hari pembaruan tersebut berada di repositori updates-testing.

Pendorongan dapat dilakukan oleh pemelihara atau secara otomatis oleh Bodhi:

  • Pembaruan menjadi layak untuk didorong secara manual setelah mencapai ambang minimum “Stable by Karma” untuk pembaruan Critical path (ya, batas yang sama berlaku untuk kedua jenis pembaruan), ATAU ambang minimum “Stable by Time”.

  • Pembaruan akan didorong secara otomatis oleh Bodhi setelah mencapai ambang batas “Stable by Karma” yang dikonfigurasi, ATAU ambang “Stable by Time” yang dikonfigurasi, jika diaktifkan (“Auto-request stable based on karma?” dan “Auto-request stable based on time?”).

  • Jika pembaruan memiliki karma negatif sekecil apa pun, dorongan otomatis akan dinonaktifkan.

  • Jika pembaruan mencapai ambang “Unstable by Karma”, maka pembaruan tersebut akan dibatalkan (unpushed), artinya dihapus dari repositori updates-testing.

Pemelihara bebas menetapkan ambang batasnya sendiri, tetapi nilainya tidak boleh lebih rendah dari nilai minimum yang dijelaskan di bawah ini dan ditegakkan oleh Bodhi. Nilai bawaan sudah memadai untuk sebagian besar paket, sehingga biasanya tidak perlu memodifikasi ambang batas ini.

Pembaruan keamanan tunduk pada ambang batas yang sama seperti pembaruan lainnya.

Ambang pembaruan non-critical path

Ambang pembaruan Critical path dan EPEL

Pembaruan “Critical path” berisi setidaknya satu paket critical path. Perubahan pada definisi ini hanya dapat dilakukan oleh FESCo atau yang ditugaskan olehnya.

Masalah atau isu terkait Pembaruan

Sebagai upaya untuk belajar dari kesalahan, jika terdapat pembaruan yang menyebabkan masalah luas atau serius bagi pengguna Fedora, harap buat tiket FESCo. FESCo akan mendiskusikan dan berupaya mencegah agar masalah serupa tidak terjadi lagi. Catatan masa lalu mengenai kejadian semacam ini dapat ditemukan di Updates Lessons.

OpenQA menjalankan pengujian terhadap pembaruan critpath di rilis stabil serta artefak komposisi untuk Rawhide, cabang, dan kandidat rilis.

Fedora CI menjalankan pengujian pada semua pembaruan Bodhi. Jika pemelihara paket menandai pengujian sebagai penghalang (blocking), pembaruan Bodhi akan ditahan dari status stabil.

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