m (→Introduction) |
Maxamillion (talk | contribs) No edit summary |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{admon/important|This page is deprecated| All Fedora Release Engineering Documentation has moved [https://docs.pagure.org/releng/ here] with source hosted along side the code in the [https://pagure.io/releng releng pagure repository]}} | |||
= Fedora Release Engineering = | = Fedora Release Engineering = | ||
| Line 4: | Line 6: | ||
== Introduction == | == Introduction == | ||
The development of Fedora is a very open process | The development of Fedora is a very open process, involving over a thousand package maintainers (along with testers, translators, documentation writers and so forth). These maintainers are responsible for the bulk of Fedora distribution development. An elected [[Fedora_Engineering_Steering_Committee|committee of people]] provides some level of direction over the engineering aspects of the project. | ||
The rapid pace of Fedora development leaves little time for polishing the development system into a quality release. To solve this dilemma, the Fedora project makes use of regular freezes and milestone (Alpha, Beta, Final) releases of the distribution, as well as "branching" of our trees to maintain different strains of development. | |||
Stable branches of the Fedora tree and associated [[Repositories]] are maintained for each Fedora release. The [[Releases/Rawhide|Rawhide]] rolling development tree is the initial entry point for all Fedora development, and the trunk from which all branches diverge. Releases are [[Releases/Branched|Branched]] from Rawhide some time before they are sent out as stable releases, and the milestone releases (Alpha, Beta and Final) are all built from this Branched tree. | |||
Nightly snapshot images of various kinds are built from Rawhide and Branched (when it exists) and made available for download from within the trees on the [https://mirrors.fedoraproject.org/ mirrors] or from the [[Koji]] build system. Many of these can be located via the [https://apps.fedoraproject.org/releng-dash/ release engineering dashboard]. | |||
The [[Fedora Release Life Cycle]] page is a good entry point for more details on these processes. Some other useful references regarding the Fedora release process include: | |||
* The [[Changes/Policy|Release planning process]] | |||
* The [[QA:Release_validation_test_plan|release validation test plan]] | |||
* The [[QA:Updates_Testing|updates-testing process]], via [[Bodhi]] and the [[Updates Policy]] | |||
* The [[QA:SOP_compose_request|test compose and release candidate system]] | |||
* The [[QA:SOP_blocker_bug_process]] and [[QA:SOP_freeze_exception_bug_process]] | |||
* The [[Repositories]] | |||
* The [[BugsAndFeatureRequests|Bugzilla system]] | |||
== Final Release Checklist == | == Final Release Checklist == | ||
Various tasks need to be accomplished prior to a final Fedora release. Release Engineering is responsible for many of them, as outlined here. | Various tasks need to be accomplished prior to a final Fedora release. Release Engineering is responsible for many of them, as outlined here. | ||
=== Export Approval === | === Export Approval === | ||
| Line 42: | Line 34: | ||
=== Release Announcement === | === Release Announcement === | ||
The [[DocsProject| | The [[DocsProject|Fedora Documentation Project]] prepares release announcements for the final releases. A bug needs to be [https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Documentation&op_sys=Linux&target_milestone=---&bug_status=NEW&version=devel&component=release-notes&rep_platform=All&priority=normal&bug_severity=normal&assigned_to=relnotes%40fedoraproject.org&cc=&estimated_time_presets=0.0&estimated_time=0.0&bug_file_loc=http%3A%2F%2F&short_desc=RELNOTES%20-%20Summarize%20the%20release%20note%20suggestion%2Fcontent&comment=Provide%20details%20here.%20%20Do%20not%20change%20the%20blocking%20bug.&status_whiteboard=&keywords=&issuetrackers=&dependson=&blocked=151189&ext_bz_id=0&ext_bz_bug_id=&data=&description=&contenttypemethod=list&contenttypeselection=text%2Fplain&contenttypeentry=&maketemplate=Remember%20values%20as%20bookmarkable%20template&form_name=enter_bug filed] for this two weeks before the final release date. | ||
=== Mirror List Files === | === Mirror List Files === | ||
| Line 50: | Line 42: | ||
=== Update Tool === | === Update Tool === | ||
The Fedora Update tool will need to be updated to handle update requests for the new release. This | The Fedora Update tool will need to be updated to handle update requests for the new release. Updates for the new release should start to be pushed a few days before the release date. This will allow for ensuring the update process will work, and to get eyes on the update bits before the rest of the world gets them. This will also allow those who were early adopters of Fedora to get updates after the final bits have been composed into a release. | ||
<!-- | |||
*** ADAMW 2014-09 *** | |||
This entire section is clearly heavily outdated, but I don't know if anything should replace it, so I felt better about commenting it out than burning it down. | |||
=== Git Branching === | === Git Branching === | ||
| Line 65: | Line 59: | ||
'''Note''': Requests for new F-(X-2) packages when F-X goes gold will not be accepted. For example, when Fedora 10 is released, no new package requests for Fedora 8 will be accepted. | '''Note''': Requests for new F-(X-2) packages when F-X goes gold will not be accepted. For example, when Fedora 10 is released, no new package requests for Fedora 8 will be accepted. | ||
--> | |||
== Release Composing == | == Release Composing == | ||
Fedora “releases” can be built by anyone with a fast machine of proper arch and access to a package repository. All of the tools necessary to build a release are available from the package repository. These tools aim to provide a consistent way to build Fedora releases. A complete release can actually be built with only a couple commands, including the creation of | Fedora “releases” can be built by anyone with a fast machine of proper arch and access to a package repository. All of the tools necessary to build a release are available from the package repository. These tools aim to provide a consistent way to build Fedora releases. A complete release can actually be built with only a couple commands, including the creation of network install images, offline install images ('DVDs'), live images, disk images, install repositories, and other bits. These commands are named pungi and livecd-creator. | ||
=== Pungi === | === Pungi === | ||
[https://fedorahosted.org/pungi Pungi] is the tool used to compose Fedora releases. It requires being ran in a chroot of the package set that it is composing. This ensures that the correct userland tools are used to match up with the kernel that will be used to perform the installation. It uses a comps file + yum repos to gather packages for the compose. The | [https://fedorahosted.org/pungi Pungi] is the tool used to compose Fedora releases. It requires being ran in a chroot of the package set that it is composing. This ensures that the correct userland tools are used to match up with the kernel that will be used to perform the installation. It uses a comps file + yum repos to gather packages for the compose. The [[Koji]] build system provides a way to run tasks within chroots on the various arches, as well as the ability to produce yum repos of packages from specific collections. | ||
=== Livecd-creator === | === Livecd-creator === | ||
Livecd-creator is part of the [[FedoraLiveCD | livecd-tools]] package in Fedora and it is used to compose the live images | Livecd-creator is part of the [[FedoraLiveCD | livecd-tools]] package in Fedora and it is used to compose the live images as part of the Fedora release. It is also used to compose many of the custom [https://spins.fedoraproject.org Spins] or variants of Fedora. | ||
== Distribution == | == Distribution == | ||
Once a compose has been completed, the composed tree of | Once a compose has been completed, the composed tree of release media, installation trees, and frozen [[Repositories]] needs to be synchronized with the Fedora mirror system. [[MirrorManager]] has some more details on the mirror system. Many of the images are also offered via BitTorrent as an alternative method of downloading. | ||
=== Download Mirrors === | === Download Mirrors === | ||
| Line 88: | Line 82: | ||
=== BitTorrent === | === BitTorrent === | ||
BitTorrent is currently served by http://torrent.fedoraproject.org. | BitTorrent is currently served by http://torrent.fedoraproject.org. Images are added to the system via this [[Infrastructure/SOP/TorrentRelease|Standard Operating Procedure]]. | ||
== Acknowledgements == | == Acknowledgements == | ||
This document was influenced by [http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html release engineering documents] | This document was influenced by [http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html release engineering documents] from [http://freebsd.org FreeBSD]. | ||
[[Category:Release Engineering]] | [[Category:Release Engineering]] | ||
Latest revision as of 17:48, 3 November 2015
All Fedora Release Engineering Documentation has moved here with source hosted along side the code in the releng pagure repository
Fedora Release Engineering
Introduction
The development of Fedora is a very open process, involving over a thousand package maintainers (along with testers, translators, documentation writers and so forth). These maintainers are responsible for the bulk of Fedora distribution development. An elected committee of people provides some level of direction over the engineering aspects of the project.
The rapid pace of Fedora development leaves little time for polishing the development system into a quality release. To solve this dilemma, the Fedora project makes use of regular freezes and milestone (Alpha, Beta, Final) releases of the distribution, as well as "branching" of our trees to maintain different strains of development.
Stable branches of the Fedora tree and associated Repositories are maintained for each Fedora release. The Rawhide rolling development tree is the initial entry point for all Fedora development, and the trunk from which all branches diverge. Releases are Branched from Rawhide some time before they are sent out as stable releases, and the milestone releases (Alpha, Beta and Final) are all built from this Branched tree.
Nightly snapshot images of various kinds are built from Rawhide and Branched (when it exists) and made available for download from within the trees on the mirrors or from the Koji build system. Many of these can be located via the release engineering dashboard.
The Fedora Release Life Cycle page is a good entry point for more details on these processes. Some other useful references regarding the Fedora release process include:
- The Release planning process
- The release validation test plan
- The updates-testing process, via Bodhi and the Updates Policy
- The test compose and release candidate system
- The QA:SOP_blocker_bug_process and QA:SOP_freeze_exception_bug_process
- The Repositories
- The Bugzilla system
Final Release Checklist
Various tasks need to be accomplished prior to a final Fedora release. Release Engineering is responsible for many of them, as outlined here.
Export Approval
As a U.S. based company, Red Hat needs to file for export approval when creating Fedora releases. Currently this involves giving Red Hat Legal a heads up at the final freeze date, and updating Legal once the final tree has been spun.
Release Announcement
The Fedora Documentation Project prepares release announcements for the final releases. A bug needs to be filed for this two weeks before the final release date.
Mirror List Files
A new set of mirror list files need to be created for the new release. Email Fedora Mirror Admins to have these files created. These should be created at the Final Freeze point but may redirect to Rawhide until final bits have been staged.
Update Tool
The Fedora Update tool will need to be updated to handle update requests for the new release. Updates for the new release should start to be pushed a few days before the release date. This will allow for ensuring the update process will work, and to get eyes on the update bits before the rest of the world gets them. This will also allow those who were early adopters of Fedora to get updates after the final bits have been composed into a release.
Release Composing
Fedora “releases” can be built by anyone with a fast machine of proper arch and access to a package repository. All of the tools necessary to build a release are available from the package repository. These tools aim to provide a consistent way to build Fedora releases. A complete release can actually be built with only a couple commands, including the creation of network install images, offline install images ('DVDs'), live images, disk images, install repositories, and other bits. These commands are named pungi and livecd-creator.
Pungi
Pungi is the tool used to compose Fedora releases. It requires being ran in a chroot of the package set that it is composing. This ensures that the correct userland tools are used to match up with the kernel that will be used to perform the installation. It uses a comps file + yum repos to gather packages for the compose. The Koji build system provides a way to run tasks within chroots on the various arches, as well as the ability to produce yum repos of packages from specific collections.
Livecd-creator
Livecd-creator is part of the livecd-tools package in Fedora and it is used to compose the live images as part of the Fedora release. It is also used to compose many of the custom Spins or variants of Fedora.
Distribution
Once a compose has been completed, the composed tree of release media, installation trees, and frozen Repositories needs to be synchronized with the Fedora mirror system. MirrorManager has some more details on the mirror system. Many of the images are also offered via BitTorrent as an alternative method of downloading.
Download Mirrors
Depends on the Fedora Mirror System and infrastructure to populate them privately.
BitTorrent
BitTorrent is currently served by http://torrent.fedoraproject.org. Images are added to the system via this Standard Operating Procedure.
Acknowledgements
This document was influenced by release engineering documents from FreeBSD.