Repositori Fedora

Untuk rilis stabil, fedora mewakili keadaan rilis yang dibekukan. Ini merupakan bagian dari pohon rilis yang dibekukan yang dibuat oleh Release Engineering saat rilis disetujui dalam pertemuan Go/No-Go Meeting. Kumpulan paket yang dikandungnya tidak pernah berubah setelah waktu tersebut. Ini mewakili keadaan stable dari rilis stabil bersama dengan repositori updates.

Repositori rilis stabil fedora untuk berbagai arsitektur utama dapat ditemukan di direktori /fedora/linux/releases/XX/Everything pada cermin (di mana XX adalah nomor rilis), dan juga dapat diakses melalui MirrorManager. Misalnya, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-43&arch=x86_64 akan menampilkan cermin untuk repositori fedora arsitektur x86_64 pada rilis 43.

Dalam rilis Branched - keadaan rilis antara cabang dari Rawhide dan rilis stabil, lihat Branched untuk detail lebih lanjut - repositori Fedora saja mewakili keadaan stabil rilis tersebut. Repositori updates untuk rilis Branched tidak digunakan hingga rilis tersebut menjadi stabil. Sebelum aktivasi repositori updates-testing, paket yang dibangun untuk rilis Branched dikirim langsung ke repositori ini. Setelah titik aktivasi Bodhi, paket yang lulus kebijakan pembaruan berpindah dari repositori updates-testing ke repositori ini.

Repositori fedora yang bercabang untuk berbagai arsitektur utama architectures dapat ditemukan di direktori /fedora/linux/development/XX pada cermin (di mana XX adalah versi rilis), dan juga dapat diakses melalui MirrorManager. Misalnya, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-44&arch=x86_64 akan menampilkan cermin untuk repositori fedora arsitektur x86_64 pada rilis 44.

Repositori updates-testing tersedia untuk rilis Branched setelah titik aktivasi Bodhi, serta untuk rilis stabil. Repositori ini diwakili oleh DNF dalam berkas fedora-updates-testing.repo di jalur repositori. Untuk keduanya, ini adalah lokasi ‘staging’ di mana pembaruan paket baru diuji sebelum ditandai sebagai ‘stable’ (dan oleh karena itu dipindahkan ke repositori fedora atau repositori updates, masing-masing).

Build-build ini kadang-kadang disebut sebagai kandidat pembaruan, dan direview menggunakan alat umpan balik pembaruan Bodhi, sesuai dengan pedoman umpan balik.

Kebijakan Pembaruan mendefinisikan aturan untuk menandai kandidat pembaruan sebagai stable. Halaman QA updates-testing menyediakan informasi bagi penguji tentang penggunaan repositori ini. Panduan Pembaruan Paket memberikan informasi bagi pengemas paket tentang cara mengirimkan build ke repositori updates-testing dan stable.

Repositori updates-testing diaktifkan secara default untuk rilis Branched, tetapi dinonaktifkan secara default untuk rilis stabil. Perpindahan ini dilakukan sekitar waktu Final Freeze untuk setiap rilis. Penguji yang beralih dari rilis Branched ke rilis stabil mungkin mengalami kesalahan saat menjalankan pembaruan pada waktu ini, disebabkan oleh ketidakcocokan dependensi antara paket yang sudah diinstal dari repositori updates-testing yang kini dinonaktifkan. Menjalankan dnf distro-sync atau mengaktifkan kembali repositori updates-testing biasanya akan mengatasi masalah ini; keputusan untuk terus menggunakan repositori updates-testing setelah rilis stabil sepenuhnya tergantung pada pengguna masing-masing.

Repositori updates-testing untuk rilis Branched dan stable dapat ditemukan di direktori /fedora/linux/updates/testing/XX pada cermin (di mana XX adalah rilis), dan juga dapat diakses melalui MirrorManager. Misalnya, https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f43&arch=x86_64 akan menampilkan cermin untuk repositori updates-testing x86_64 pada rilis 43.

Di Rawhide - repositori rilis berkelanjutan Fedora, dari mana cabang-cabang dibuat sebelum akhirnya menjadi stabil - rawhide adalah repositori tunggal. Semua paket yang dibangun dikirim ke sana. Repositori ini diwakili oleh DNF dalam berkas fedora-rawhide.repo di jalur repositori. Untuk sistem apa pun yang menjalankan Rawhide, repositori ini harus diaktifkan. Untuk sistem lain, repositori ini tidak boleh diaktifkan.

Repositori rawhide untuk berbagai arsitektur utama architectures dapat ditemukan di direktori pada cermin, dan juga dapat diakses melalui MirrorManager. Misalnya, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 akan menampilkan mirror untuk repositori fedora x86_64 di Rawhide.

Tidak jarang menemukan referensi ke ‘repositori stabil’, namun istilah ini agak menyesatkan. stable lebih merujuk pada kondisi yang dapat dianggap ada baik untuk rilis Branched setelah Bodhi enabling maupun untuk rilis stabil. Repositori ini terdiri dari paket-paket yang merupakan bagian dari Rawhide pada saat mereka di-branch, paket-paket yang dikirim langsung ke repositori fedora yang di-branch antara titik branch dan titik aktivasi Bodhi, serta paket-paket yang lolos kebijakan pembaruan dan dipindahkan dari updates-testing setelah titik aktivasi Bodhi.

Untuk rilis Branched, status stable hanya diwakili oleh isi saat ini dari repositori fedora (dan, secara argumen, repositori bleed, tetapi itu adalah kasus yang kecil).

Untuk rilis stabil, status stable diwakili oleh isi repositori fedora yang digabungkan dengan isi repositori updates.

stable juga merupakan status yang dapat dimiliki oleh sebuah paket (atau atribut yang dapat dimilikinya) ketika paket tersebut telah dipindahkan ke repositori stabil atau ditandai sebagai stabil dan berada di, atau akan segera berada di, repositori stabil untuk sebuah rilis - repositori mana pun yang dimaksud (lihat di atas).

Repositori bleed dibuat untuk satu tujuan: selama pembekuan milestone, repositori ini berisi paket-paket yang telah diberikan ‘kecualian pembekuan’ melalui proses bug pemblokir atau https://fedoraproject.org/wiki/QA: SOP_freeze_exception_bug_process[Proses Bug Kecualian Pembekuan], dan yang diinginkan untuk dimasukkan ke dalam build komposisi uji atau kandidat rilis berikutnya, tetapi belum mencapai status stable dan oleh karena itu belum dipindahkan ke repositori fedora. Dengan kata lain, repositori ini berisi paket-paket yang secara eksplisit diperlukan dalam permintaan komposisi TC/RC .

Repositori bleed dapat ditemukan di sini, tetapi sekali lagi, biasanya tidak menarik bagi sebagian besar pengguna Fedora. Paket-paket yang terdapat di dalamnya selalu juga tersedia dari sistem build, Koji, dan biasanya dari repositori updates-testing.

Repositori latest berisi paket untuk berbagai ‘tag’ build saat mereka tiba di sistem build Koji. Paket-paket ini tidak digabungkan, suatu proses yang terutama menangani multilib, dan menggunakannya dapat menyebabkan berbagai masalah, selain membebani server pengembangan Fedora. Sangat disarankan untuk memilih build baru secara selektif dari Koji atau Bodhi melalui antarmuka web atau alat baris perintah mereka.

Seperti yang dijelaskan di atas, pembaruan untuk both Branched pre-releases dan rilis final yang stable melalui proses updates-testing sebelum dipindahkan ke repositori stable. Sebelum rilis final, pembaruan tersebut ditempatkan di repositori fedora. Setelah rilis, pembaruan tersebut ditempatkan di repositori updates.

Alasan perbedaan ini adalah karena kami ingin memiliki catatan tentang keadaan tepat dari suatu rilis stabil Fedora. Artinya, pada saat rilis Fedora dinyatakan selesai dalam pertemuan Go/No-Go Meeting, kami menganggap keadaan rilis pada saat itu sebagai definisi kanonik dari rilis tersebut, dan kami ingin menyimpan catatan tentang keadaan tersebut. Untuk rilis stabil, pohon yang berisi repositori fedora adalah catatan tersebut, dan repositori fedora yang dikandungnya adalah catatan kanonik dari kumpulan paket yang dibekukan (frozen) secara tepat yang membentuk bagian utama dari rilis stabil tersebut.

Karena kami ingin mempertahankan keadaan frozen untuk repositori fedora, kami tidak dapat menempatkan pembaruan langsung ke dalamnya. Kebutuhan akan repositori updates pun menjadi jelas - kami memerlukan tempat untuk menempatkan pembaruan untuk rilis stabil yang berada di luar keadaan frozen dari rilis tersebut.

Sebelum rilis stabil diluncurkan, mekanisme ini tidak diperlukan. Sebelum rilis dinyatakan selesai, tidak ada keadaan frozen dari rilis tersebut: secara efektif, seluruh proses pengembangan Branched sedang berusaha mencapai keadaan frozen dari rilis tersebut, jadi tentu saja paket-paket untuk rilis Branched langsung ditempatkan di repositori fedora.

Meskipun rilis pengembangan bercabang (Branched) dan rilis stabil (Stable) keduanya menggunakan repositori updates-testing bersama dengan sistem umpan balik pembaruan Bodhi untuk menguji paket sebelum mencapai status stable rilis, fitur ini diaktifkan secara default di Branched, tetapi tidak di rilis stabil.

Alasan utamanya adalah bahwa tujuan sistem updates-testing sedikit berbeda dalam setiap kasus. Untuk rilis stabil, tujuan sistem ini adalah mencegah pembaruan yang bermasalah mencapai populasi pengguna Fedora secara umum. Dalam kebanyakan kasus, sistem Fedora diharapkan memiliki repositori updates-testing yang dinonaktifkan. Beberapa penguji QA kemudian mengaktifkan repositori tersebut pada sistem pengujian untuk mencoba pembaruan dan memberikan umpan balik. Penguji tersebut bertugas memastikan pembaruan tersebut aman sebelum mencapai populasi pengguna umum.

Ketika berbicara tentang rilis pra-rilis Branched, diharapkan bahwa siapa pun yang menginstalnya ingin membantu mengujinya: kami secara efektif menganggap siapa pun yang menjalankan rilis Branched sebagai penguji. Fungsi updates-testing berbeda dalam hal ini. Tidak ada ‘populasi pengguna umum’ dari pengguna Branched yang menjalankan updates-testing dalam keadaan dinonaktifkan, dan dilindungi dari pembaruan bermasalah oleh kelompok penguji pembaruan. Sebaliknya, updates-testing dalam Branched memiliki fungsi penting lainnya.

Tujuan utama adalah untuk melindungi image builds dari perubahan yang berpotensi menimbulkan masalah. Image yang di-branch - image harian, serta build milestone Alpha, Beta, dan GA (Final) dan build kandidat rilis uji coba-nya - dibangun dari paket-paket stable, yaitu hanya yang ada di repositori fedora, bukan yang ada di updates-testing. Dalam hal ini, updates-testing melindungi bukan sekumpulan pengguna, tetapi sekumpulan build, dari perubahan yang berpotensi mengganggu stabilitas. Terutama saat kita membangun rilis Alpha, Beta, atau GA, kita perlu dapat mengurangi jumlah perubahan dalam kumpulan paket antara komposisi untuk menghasilkan image berkualitas tinggi. Mekanisme updates-testing memungkinkan hal ini: selama pembekuan Milestone, build baru dapat dikirim ke updates-testing, tetapi tidak dapat berpindah dari sana ke stable (fedora) tanpa keadaan khusus. Dengan cara ini, kita dapat bekerja pada image rilis tanpa menghalangi pengemas untuk mengirimkan build.

Untuk fungsi ini dan fungsi lain yang kurang penting, kami membutuhkan sebanyak mungkin umpan balik, jadi masuk akal untuk mengaktifkan updates-testing secara default untuk semua penguji pra-rilis, dan mendorong mereka untuk memberikan umpan balik melalui Bodhi.

Menemukan kesalahan ketik, informasi yang hilang atau sudah tidak berlaku, atau hal lain yang dapat diperbaiki? Edit dokumen ini di https://pagure.io/fedora-docs/quick-docs.