FedoraSummit/ReleaseProcess

Fedora: Proposed Changes to the Release Process

The Goal of the Proposal

To figure out the right way to structure the release process in a new world where there is no difference between "Extras" and "Core" and "Legacy".

What the Fedora Project Will Deliver

Every six months or so, something will come out with the Fedora name attached ot it. Right now, that thing is called "Fedora Core".

In future, the Fedora Project, as a whole, will release:

• A whole bunch of packages, to be known temporarily as "Fedora Complete", which is all packages formerly contained in Fedora Core and Fedora Extras;
• A distribution called "Fedora Desktop" or something similar, which is a collection of desktop-related packages (GNOME, X, Firefox, etc.) from Fedora Complete;
• A distribution called "Fedora Server" or something similar, which is a collection of server-related packages (LAMP stack, maybe JBoss, etc.) from Fedora Complete;
• A set of tools (pungi, pilgrim, etc.) that make it possible to compose distributions based on Fedora Complete.

Development Process Pre-Release: Rawhide

• "Rawhide" is the name for all packages in Fedora Complete that are being prepared for the next release. For example: the packages that are currently being built in anticipation of FC-7 are called "rawhide".
• Rawhide packages will be built and pushed into the rawhide repo on a regular basis (at least daily).
• Rawhide is, essentially, a rolling release. If you want to build it, build it.
• A separate Rawhide installer will be built separately containing no packages, but the ability to connect to yum repositories such as Rawhide or previous test releases.
• At some point, certain Rawhide packages will be garbage collected -- precise policy to be determined.

Development Process Near Release: Freeze

• Near a release time -- test release, final release, whatever -- a "freeze" tag will be applied to every package in Fedora Complete.
• Test repos and composes will be made from packages tagged with the freeze tag.
• When fixes need to be made to the release, those fixed builds in the base tag are tagged with the freeze tag
• Base collection will continue to roll as normal.
• At final release, the SCM will be branched, and devel will continue to roll.

Example: The "dist-fc7" tag applies to every package built from the devel branch currently. When we get to time for FC7 test 1, we create the "fc7-test1" tag (freeze tag). We tag the latest packages from dist-fc7 with this "fc7-test1" freeze tag. We create a test repo of all packages tagged "fc7-test1", and we spin test1 versions of the distro with these packages. Fixes are applied to the devel branch and built. Resulting specific package builds get tagged with "fc7-test1" at the discretion of the release team. At final release, we create "fc7" branch and devel rolls on in "dist-fc8".

Development Process Post-Release: Updates

The following update process is proposed for any update to any package in Fedora Complete. Essentially, this will mean that we no longer have a "rolling release" after the release of Fedora Complete.

• Build a package from the released branch. (We're also look at building post-processing tools that can help figure out "how many packages you're breaking" and such).
• Go to the "update tool" and request update to repo, filling out the

necessary data, maybe bug numbers as well, and submit.

• Release team is notified that package update request is pending.
• Release team sanity checks, signs, and pushes package goes into the updates-testing repository.
• Package sits in updates-testing for some defined timeout period -- for the sake of argument, let's say a week. Ideally, we will build strong testing mechanisms allowing testers (or even just plain ol' users) the opportunity to evaluate these packages and give them +1/-1 -- but realistically, the package may just sit for a week.
• After timeout, email is sent to packager and release team. Ultimately, that email may have all kinds of information: "15 people loved your update, 3 hated it" -- but in the short term, it's likely to say "your package has been in updates-testing for a week; be sure to check bugzilla. If no one has complained, resubmit for final approval."
• Final review is submitted via update tool, and updates team evaluates.
• Change goes live! (Or, in the sad alternate ending, the updates team says something like "we don't care how good this looks on paper, it will force a rebuild of 1500 packages" and they will deny the request.)

Development Process: End-of-Life

The Fedora Legacy project was formed originally to maintain the old RHL products after they were EOL'd by Red Hat. In recent years, though, the Legacy Project has had fewer and fewer contributors; most people who want to maintain a free distro for a longer period of time use other alternatives. For those who do want to use Fedora, though, it's clear that we need a slightly longer lifecycle.

Therefore, we're proposing replacing the offical Fedora Legacy project with a Fedora Security Project, that will be responsible for handling security updates for Fedora after its release. We propose that the Fedora Security Team should manage Legacy for FC5 and FC6.

Current end of life: FCn+2 test 2 (approximately 9 months)

Proposed end of life: FCn+2 plus one month (approximately 13 months)

Action Items

• Propose to Legacy team

Legacy has received proposal and is mostly on board, so long as the Legacy project could be revived should there prove interest.

• Propose to Extras team
• Propose to Red Hat engineering
• Build a real action plan based on proposal