From Fedora Project Wiki
m (→‎History: use wikilinks)
(5 intermediate revisions by the same user not shown)
Line 3: Line 3:
= Branched =
= Branched =


Branched is the name given to a version of Fedora that has "branched" off of Rawhide and will become the next stable Fedora release. It consists of a package repository named with the Fedora version it will become and contains builds of all Fedora packages updated by maintainers with the goal of stablizing before release and fixing any release features. Nightly live image builds are also available during the later portion of the [[Fedora Release Life Cycle]].
Branched is the name given to a version of Fedora that has "branched" from the rolling [[Releases/Rawhide|Rawhide]] tree and will become the next stable Fedora release. It consists of [http://download.fedoraproject.org/pub/fedora/linux/development/{{FedoraVersionNumber|next}} a Fedora development release tree]<ref>Link will only work when a Branched release currently exists.</ref> named after the Fedora release it will become. It contains builds of all Fedora packages updated by maintainers with the goal of stabilizing before release and fixing any release [[Changes/Policy|Changes]]. Nightly live and disk image builds are also [https://apps.fedoraproject.org/releng-dash/ produced], and installer, upgrade and PXE boot images may be available within the tree.


Branched is sometimes referred to by the Fedora release it will become. ie, "Fedora 19 Branched"  
Branched may be referred to by the Fedora release it will become, e.g. "{{FedoraVersion|long|next}} Branched".
 
<references/>


== Goals ==
== Goals ==


Branched has the following Goals:  
Branched has the following goals:  


* To allow package maintainers to integrate their packages into Fedora for a stable release.  
* To allow package maintainers to integrate their packages into Fedora for a stable release.  
Line 37: Line 39:
=== Live media ===
=== Live media ===


After the [[Releases/{{FedoraVersion||next}}|Branch event]], but before the Fedora stable release,  [http://alt.fedoraproject.org/pub/alt/nightly-composes/ nightly builds] will be composed from Branched. You may be able to use these automated Live images to boot and test Branched. These images are automatically composed and not tested by [[QA]]
After the [[Releases/{{FedoraVersion||next}}|Branch event]], but before the Fedora stable release,  [https://apps.fedoraproject.org/releng-dash/ nightly live image builds] will be composed from Branched. You may be able to use these images to boot and test Branched. These images are automatically composed and not tested by [[QA]].


=== Virtual instances  ===
=== Virtual instances  ===
Line 47: Line 49:
=== Getting a Branched install ===
=== Getting a Branched install ===


The Branched tree is directly installable (barring problems).  
The [[Repositories#product|Product trees]] within the Branched tree should be directly installable (barring problems).


==== Install from Live media ====
==== Install a pre-release ====


If Live media are being composed from Branched (see above), you may be able to download the Live media, copy it to local media, boot and install Branched.  
If the Branched release has already spawned an Alpha or Beta release, you can simply install that - it should be available from [https://fedoraproject.org/get-prerelease a Fedora download page] - and then update as usual. Installing a pre-release and following normal update procedures will result in your installation tracking the Branched release.


This is the most fragile way to get a Branched install, as Live media is only produced at some points in the cycle, sometimes does not compose, and when it does, may not install correctly.  
Before each of the above milestones, [[QA:SOP_compose_request#Test_composes|test compose and release candidate]] images are sometimes available. These are produced as part of the [[QA:Release_validation_test_plan|process of validating releases]].


==== Point installer to Branched ====
TC images may or may not install correctly.


You can sometimes install Branched by using a stable install media and pointing it to the Rawhide repository for packages to install.  
RC images may or may not install correctly, but you can usually find the [http://qa.fedoraproject.org/blockerbugs/current list of known blockers] to see if they affect you.  


# Download the latest stable or branched install media. (netinstall or DVD install)
==== Install from nightly live or disk media ====
# Copy to local media (USB or DVD or CD)
# Boot media and go to the 'Install Source' section and manually enter:<br />https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/<br />(or i386 for 32bit)
# Finish the install as normal.


For this method to work, there should be no major changes in Branched that the installer is not ready for, such as packages it depends on being retired or other similar situations.
If Live media are being composed from Branched (see above), you may be able to download the Live media, copy it to local media, boot and install Branched. In the same place, you will find nightly builds of the disk images for [[Architectures/ARM|ARM]] and [[Cloud]] platforms.


==== Yum from Existing install ====
This is the most fragile way to get a Branched install, as Live media are only produced at some points in the cycle, sometimes does not compose, and when it does, may not install correctly.


You may use yum to upgrade from the most recent Stable or Branched release. You will need to have such an install in place and should likely update to the newest updates before starting.
==== Point installer to Branched ====


See [[Upgrading_Fedora_using_yum#To_rawhide|Upgrading Fedora using yum Branched info]]
You can sometimes install Branched by using a stable install media and pointing it to the Branched repositories for packages to install.


This method may fail if there are upgrade path issues (newer packages in Stable or Branched than Branched), or broken dependencies.  
# Download the latest stable or branched install media (network install or offline ("DVD") installer image)
# Copy to local media ([[How_to_create_and_use_Live_USB|USB]] or [https://docs.fedoraproject.org/en-US/Fedora/{{FedoraVersionNumber}}/html/Burning_ISO_images_to_disc/index.html DVD or CD])
# Boot media and go to the 'Installation Source' screen and manually enter: {{filename|https://download.fedoraproject.org/pub/fedora/linux/development/{{FedoraVersionNumber|next}}/x86_64/os/}}(or i386 for 32-bit)
# Finish the install as normal.  


==== Latest milestone or test images ====
For this method to work, there should be no major changes in Branched that the installer is not ready for, such as packages it depends on being retired or other similar situations.


At Alpha, Beta and final, a set of install images (DVD and netinstall) and live images for desktops are produced. You can use these to install branched.
==== Yum from existing stable install ====


Before each of the above milestones, TC and RC images are sometimes available. TC or Test Compose imags are done before milestones when there are known release blocking bugs that need addressing. RC images (Release Candidate) are produced when all known blocker bugs for a release are addressed. If no further blocker bugs are found in an RC image, that RC will become (with no further changes) the release.  
You may use yum to upgrade from the most recent stable release. You will need to have such an install in place and should likely update to the newest updates before starting.  


TC images may or may not install correctly.
See [[Upgrading_Fedora_using_yum#To_Fedora_{{FedoraVersionNumber|next}}_pre-release|Upgrading Fedora using yum Branched info]]


RC images may or may not install correctly, but you can usually find the list of known blockers to see if they affect you.
This method may fail if there are upgrade path issues (newer packages in stable or than Branched), or broken dependencies.  
 
Alpha and Beta images should install correctly in most cases. This is the preferred way to install if those milestones have been reached.  


=== Communicating  ===
=== Communicating  ===
Line 100: Line 100:
==== Bugzilla ====
==== Bugzilla ====


Branched bugs should be reported against the Fedora Product, and version that this branched will become and the affected component.  Please do follow [[BugsAndFeatureRequests|best practices]] when filing. Remember that IRC and mailing lists are useful to help narrow down if some behavior is a bug or where to report it, but are themselves not bug reporting channels. Always file bugs in [http://bugzilla.redhat.com Bugzilla].
Branched bugs should be reported against the Fedora Product, and version that this branched will become and the affected component.  Please do follow [[BugsAndFeatureRequests|best practices]] when filing. Remember that IRC and mailing lists are useful to help narrow down if some behavior is a bug or where to report it, but are themselves not bug reporting channels. Always file bugs in [https://bugzilla.redhat.com Bugzilla].


Note that broken dependencies are mailed to maintainers for each daily Branched compose where a package has such broken dependencies. Therefore, it's usually not worth filing a bug for broken dependencies unless they don't appear in the daily report, or you have a fix or improvement to suggest.
Note that broken dependencies are mailed to maintainers for each daily Branched compose where a package has such broken dependencies. Therefore, it's usually not worth filing a bug for broken dependencies unless they don't appear in the daily report, or you have a fix or improvement to suggest.
Line 106: Line 106:
== Producing Branched ==
== Producing Branched ==


Branched goes through several phases:
The Branched compose runs every day starting at 09:15UTC. All branched builds at that time that are marked as [[Repositories#stable|''stable']] are composed and synced out. Note that during freezes there will be many days where 0 packages are added to the compose. The Branched tree is under {{filename|development/VERSION}} on the mirrors. You can find a local "{{FedoraVersionNumber|next}}" mirror [http://mirrors.fedoraproject.org/publiclist/Fedora/{{FedoraVersionNumber|next}}/ on the public mirror list]. Compose time varies depending on number of changes but is typically between 5 and 8 hours.  
 
The Branched compose runs every day starting at 09:15UTC. All branched builds at that time that are stable are composed and synced out. Note that during freezes there will be many days where 0 packages are added to the compose. Branched is under "development/VERSION" on the mirrors. You can find a local "{{FedoraVersionNumber|next}}" mirror [http://mirrors.fedoraproject.org/publiclist/Fedora/{{FedoraVersionNumber|next}}/ on the public mirror list]. Compose time varies depending on number of changes but is typically between 5 and 8 hours.
 
Right after branching off from rawhide, but before alpha change freeze, Branched is much like Rawhide. All packages built the previous day are composed and synced out. Bodhi is not used yet.
 
At alpha change freeze, Bodhi (the Fedora updates system) is enabled. All builds must now use it. Builds are pushed to updates-testing repository and after meeting critera for stable are added to the base package repository, which is still composed once a day. During the Alpha change freeze, only updates that fix accepted blocker bugs or freeze exceptions are allowed to go stable. There is also an empty updates repository, so that you can leave stable updates configured during the branch period and not have to change this after the release.
 
As soon as Alpha is set to "go", the Alpha change freeze is lifted and packages can once again go to the base repository when marked stable.
 
At the Beta change freeze, again only builds that are accepted blockers or freeze exceptions are allowed to go stable. After Beta is "go" stable builds are again pushed.  


At the Final change freeze, things happen much as Alpha and Beta, however, after Final is signed off on, the branched compose is disabled completely, and packages set to go stable are pushed to a new 'updates' repoistory and become 0 day updates.  
Branched is subject to various [[:Category:Policy|policies]] during its life cycle. For most of its existence, it is subject to the [[Updates Policy]] and package updates for it are gated through the [[Bodhi]] package review process. At various points of the [[Fedora Release Life Cycle]], other freezes, policies and requirements come into effect, including the [[Software String Freeze Policy]], the [[Milestone freezes]], and the [[Changes/Policy|Change freezes]]. See all the above links for more details on exactly what changes may occur in the Branched tree under what conditions at what times.


Composes are done in a rawhide chroot using the 'mash' tool called from a script maintained by Fedora Release engineering: http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide If the base set of packages in rawhide needed to compose rawhide are broken, the daily compose may fail.  
Composes are done in a chroot using the 'mash' tool called from a [http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide script maintained by Fedora Release engineering].  If the base set of packages needed to compose are broken, the daily compose may fail.  


A report for each Branched compose is sent to to the {{fplist|test}} and the {{fplist|devel}} lists. This report contains output from the 'repodiff' tool from the previous compose as well as a broken dependency report for packages with broken dependencies. Additionally, private email is sent to maintainers with packages containing broken dependencies.  
A report for each Branched compose is sent to to the {{fplist|test}} and the {{fplist|devel}} lists. This report contains output from the 'repodiff' tool from the previous compose as well as a broken dependency report for packages with broken dependencies. Additionally, private email is sent to maintainers with packages containing broken dependencies.  
Line 126: Line 116:
Package maintainers should read and follow the [[Updates_Policy#Branched_release|Branched release updates policy]] for building any packages in Branched.
Package maintainers should read and follow the [[Updates_Policy#Branched_release|Branched release updates policy]] for building any packages in Branched.


Branched packages are not 100% signed until the Alpha Change freeze milestone.
Until the [[Updates Policy#Bodhi enabling|Bodhi enabling point]], you cannot expect all packages in the Branched tree to be signed. To use Branched at these times, GPG signature checking in your package management tool must be disabled.


== Questions and Answers ==
== Questions and Answers ==
Line 132: Line 122:
'''Q:''' So Branched is very stable and we can all use it?  
'''Q:''' So Branched is very stable and we can all use it?  


A: No. See audience above. There are things that break from time to time, but if you are able to downgrade or troubleshoot such issues aren't too severe, however most users should stick to Stable Fedora releases.  
A: No. See audience above. There are things that break from time to time, but if you are able to downgrade or troubleshoot such issues aren't too severe, however most users should stick to stable Fedora releases.  


'''Q:''' I'm using a Stable Fedora release, but I want the newer package for foo thats only available in Branched. Can I just yum install it?
'''Q:''' I'm using a stable Fedora release, but I want the newer package for foo thats only available in Branched. Can I just yum install it?


A: No. Mixing releases like this is a very bad idea. Your better options are:  
A: No. Mixing releases like this is a very bad idea. Better options are:  


* Obtain the src.rpm for the package you wish and try and "mock rebuild" it (which may or may not work depending on dependencies)
* Obtain the src.rpm for the package you wish and try and [[Using_Mock_to_test_package_builds|mock]] rebuild it (which may or may not work depending on dependencies)
* Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.  
* Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.  


Line 153: Line 143:
* Reboot often (preferably whenever new kernels arrive). This allows you to test the boot up process and packages related to it, as well as newer kernels. Read and understand the Dracut troubleshooting steps.  
* Reboot often (preferably whenever new kernels arrive). This allows you to test the boot up process and packages related to it, as well as newer kernels. Read and understand the Dracut troubleshooting steps.  


* Follow the {{fplist|test}} and the {{fplist|devel}} lists for rawhide issues, try and at least skim them before doing your daily Branched updates. Look for '[rawhide]' subjects or reports of issues. Additionally if you find a problem and are not sure what to file bugs against you can open a discussion there.  
* Follow the {{fplist|test}} and the {{fplist|devel}} lists for Branched issues, try and at least skim them before doing your daily Branched updates. Look for '<nowiki>[</nowiki>branched<nowiki>]</nowiki>' or '<nowiki>[</nowiki>{{FedoraVersionNumber|next}}<nowiki>]</nowiki>' subjects or reports of issues. Additionally if you find a problem and are not sure what to file bugs against you can open a discussion there.  


* Branched kernels are made with a large amount of debugging enabled. You can often gain a good deal of performance by passing "slub_debug=-" to your kernel boot line in /etc/grub2.cfg. Additionally, you can run kernels in the [[RawhideKernelNodebug|Rawhide Kernel Nodebug]] repo that have all debugging disabled.  
* At some times, Branched kernels are made with a large amount of debugging enabled. You can often gain a good deal of performance by passing "slub_debug=-" to your kernel boot line in {{filename|/etc/grub2.cfg}}. Additionally, you can run kernels in the [[RawhideKernelNodebug|Rawhide Kernel Nodebug]] repo that have all debugging disabled.  


* If you are using a graphical desktop environment in your Branched install, you may wish to install several of them. This allows you to still login and troubleshoot when your primary desktop environment is not working for some reason.
* If you are using a graphical desktop environment in your Branched install, you may wish to install several of them. This allows you to still login and troubleshoot when your primary desktop environment is not working for some reason.
Line 167: Line 157:
* [[No Frozen Rawhide Proposal]]
* [[No Frozen Rawhide Proposal]]
* [[No Frozen Rawhide Implementation]]
* [[No Frozen Rawhide Implementation]]
[[Category:Releases]]
[[Category:Release Engineering]]
<references/>

Revision as of 23:46, 25 September 2014

Branched

Branched is the name given to a version of Fedora that has "branched" from the rolling Rawhide tree and will become the next stable Fedora release. It consists of a Fedora development release tree[1] named after the Fedora release it will become. It contains builds of all Fedora packages updated by maintainers with the goal of stabilizing before release and fixing any release Changes. Nightly live and disk image builds are also produced, and installer, upgrade and PXE boot images may be available within the tree.

Branched may be referred to by the Fedora release it will become, e.g. "Fedora 40 Branched".

  1. Link will only work when a Branched release currently exists.

Goals

Branched has the following goals:

  • To allow package maintainers to integrate their packages into Fedora for a stable release.
  • To allow advanced users access to the newer packages than stable releases typically provide.
  • To identify and fix issues with packages before they reach a stable release of Fedora.

Using Branched

This section discusses Branched target users and how to test Branched with Live media, within a virtual installation or on a bare metal installation.

Audience

Branched is targeted at advanced users, testers and package maintainers.

As a branched consumer, you should:

  • Be willing to update often. Branched doesn't get as many updates as rawhide (and at times they are frozen), but it still gets a larger amount than a Stable release.
  • Be willing and able to troubleshoot problems. From time to time there are problems with Branched packages, and you will need strong troubleshooting skills and the ability to gather information for bug reports. You need a good understanding of yum and how to downgrade packages, as well as boot time troubleshooting.
  • Frequent reboots to test new kernel versions and confirm functionality of the boot process. If you can't reboot often, consider using a stable release instead.
  • Be willing and able to report bugs as you find them and help maintainers gather information to fix them.

If the above doesn't match you, you may wish to instead follow the Rawhide release (depending on the point in the release cycle) or use regular stable Fedora releases.

Live media

After the Branch event, but before the Fedora stable release, nightly live image builds will be composed from Branched. You may be able to use these images to boot and test Branched. These images are automatically composed and not tested by QA.

Virtual instances

You may wish to install and run Branched in a virtual machine (VM) instance. This allows you to test when not running Linux, or avoid any impact to your day-to-day workflow.

See the section below on setting up a Branched install.

Getting a Branched install

The Product trees within the Branched tree should be directly installable (barring problems).

Install a pre-release

If the Branched release has already spawned an Alpha or Beta release, you can simply install that - it should be available from a Fedora download page - and then update as usual. Installing a pre-release and following normal update procedures will result in your installation tracking the Branched release.

Before each of the above milestones, test compose and release candidate images are sometimes available. These are produced as part of the process of validating releases.

TC images may or may not install correctly.

RC images may or may not install correctly, but you can usually find the list of known blockers to see if they affect you.

Install from nightly live or disk media

If Live media are being composed from Branched (see above), you may be able to download the Live media, copy it to local media, boot and install Branched. In the same place, you will find nightly builds of the disk images for ARM and Cloud platforms.

This is the most fragile way to get a Branched install, as Live media are only produced at some points in the cycle, sometimes does not compose, and when it does, may not install correctly.

Point installer to Branched

You can sometimes install Branched by using a stable install media and pointing it to the Branched repositories for packages to install.

  1. Download the latest stable or branched install media (network install or offline ("DVD") installer image)
  2. Copy to local media (USB or DVD or CD)
  3. Boot media and go to the 'Installation Source' screen and manually enter: https://download.fedoraproject.org/pub/fedora/linux/development/40/x86_64/os/(or i386 for 32-bit)
  4. Finish the install as normal.

For this method to work, there should be no major changes in Branched that the installer is not ready for, such as packages it depends on being retired or other similar situations.

Yum from existing stable install

You may use yum to upgrade from the most recent stable release. You will need to have such an install in place and should likely update to the newest updates before starting.

See Upgrading Fedora using yum Branched info

This method may fail if there are upgrade path issues (newer packages in stable or than Branched), or broken dependencies.

Communicating

There are a number of ways to communicate with other Branched users:

IRC

Branched discussion is on topic and welcome in both the #fedora-devel and #fedora-qa IRC channels.

Mailing Lists

Branched discussion is on topic and welcome in both the test and devel lists.

Bugzilla

Branched bugs should be reported against the Fedora Product, and version that this branched will become and the affected component. Please do follow best practices when filing. Remember that IRC and mailing lists are useful to help narrow down if some behavior is a bug or where to report it, but are themselves not bug reporting channels. Always file bugs in Bugzilla.

Note that broken dependencies are mailed to maintainers for each daily Branched compose where a package has such broken dependencies. Therefore, it's usually not worth filing a bug for broken dependencies unless they don't appear in the daily report, or you have a fix or improvement to suggest.

Producing Branched

The Branched compose runs every day starting at 09:15UTC. All branched builds at that time that are marked as stable' are composed and synced out. Note that during freezes there will be many days where 0 packages are added to the compose. The Branched tree is under development/VERSION on the mirrors. You can find a local "40" mirror on the public mirror list. Compose time varies depending on number of changes but is typically between 5 and 8 hours.

Branched is subject to various policies during its life cycle. For most of its existence, it is subject to the Updates Policy and package updates for it are gated through the Bodhi package review process. At various points of the Fedora Release Life Cycle, other freezes, policies and requirements come into effect, including the Software String Freeze Policy, the Milestone freezes, and the Change freezes. See all the above links for more details on exactly what changes may occur in the Branched tree under what conditions at what times.

Composes are done in a chroot using the 'mash' tool called from a script maintained by Fedora Release engineering. If the base set of packages needed to compose are broken, the daily compose may fail.

A report for each Branched compose is sent to to the test and the devel lists. This report contains output from the 'repodiff' tool from the previous compose as well as a broken dependency report for packages with broken dependencies. Additionally, private email is sent to maintainers with packages containing broken dependencies.

Package maintainers should read and follow the Branched release updates policy for building any packages in Branched.

Until the Bodhi enabling point, you cannot expect all packages in the Branched tree to be signed. To use Branched at these times, GPG signature checking in your package management tool must be disabled.

Questions and Answers

Q: So Branched is very stable and we can all use it?

A: No. See audience above. There are things that break from time to time, but if you are able to downgrade or troubleshoot such issues aren't too severe, however most users should stick to stable Fedora releases.

Q: I'm using a stable Fedora release, but I want the newer package for foo thats only available in Branched. Can I just yum install it?

A: No. Mixing releases like this is a very bad idea. Better options are:

  • Obtain the src.rpm for the package you wish and try and mock rebuild it (which may or may not work depending on dependencies)
  • Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.

Q: How can I tell when the branched compose for the day has finished?

A: You can see the reports it sends to the test and the devel lists. You can also watch fedmsg for the messages that rawhide compose has finished.

Hints and Tips

  • Your package management system can be of great help in diagnosing and working around issues you find. Do read up and understand: 'yum downgrade' 'yum history' 'yum update --skip-broken' 'koji download-build'.
  • You should update frequently (preferably every day). This allows you to more easily narrow down when a problem or issue appeared. If you apply a week of Branched updates at once you have many more packages to examine to narrow down issues.
  • Reboot often (preferably whenever new kernels arrive). This allows you to test the boot up process and packages related to it, as well as newer kernels. Read and understand the Dracut troubleshooting steps.
  • Follow the test and the devel lists for Branched issues, try and at least skim them before doing your daily Branched updates. Look for '[branched]' or '[40]' subjects or reports of issues. Additionally if you find a problem and are not sure what to file bugs against you can open a discussion there.
  • At some times, Branched kernels are made with a large amount of debugging enabled. You can often gain a good deal of performance by passing "slub_debug=-" to your kernel boot line in /etc/grub2.cfg. Additionally, you can run kernels in the Rawhide Kernel Nodebug repo that have all debugging disabled.
  • If you are using a graphical desktop environment in your Branched install, you may wish to install several of them. This allows you to still login and troubleshoot when your primary desktop environment is not working for some reason.
  • Have a rescue media handy of the current stable Fedora release for emergencies.

History

Branched was created as part of the "No frozen Rawhide" proposals: