ReleaseEngineering/DevelopmentChangesProposal

Proposed Development Process Changes for Fedora 9

Problem Space

Currently a Fedora development cycle consists of three test releases and the final release. Each of these releases has a collection wide freeze that effects the Rawhide compose. The freezes for the test releases last generally a week. The final release has a final freeze associated with it that lasts until the actual release is made and the next development cycle starts. Added up this can block rawhide up to two months (3 weeks during test releases, a month from last test release to final release) during an already tight development cycle (6 months). This is no longer an efficient use of developer and tester time.

Also due to the way that our CVS is set up we end up blocking developers from working on next release type changes or we wind up with these kind of changes landing in our tree that we're trying to make stable.

Proposed Solution

Move to an Alpha/Beta/RC/Final release method. Limit collection wide blocking freezes to one for a Beta release and a continual one for the RC/Final release. Allow early branching of CVS and mass branch earlier.

Note: As of the Fedora 8 Development Cycle we started allowing for early release branches. We allowed these starting at the Test 3 release.

Solution Details

Instead of doing three test releases, we would instead move to an Alpha/Beta/RC/Final release mechanism. New names have been chosen to be more descriptive of what each of these releases are trying to accomplish. The uniform "Test1/2/3" was not very descriptive, whereas Alpha, Beta, and Release Candidate are more in line with what each of these things are and how they should be treated. These names should also lend themselves better to translation into other languages.

These named releases will be time based, and the basis of our development schedule. More snapshot releases can be made that are Feature driven, or bugfix drive, or otherwise deemed useful to have but not necessarily scheduled or listed. These also may have less coordinated QA but still be useful for testers to make use of for sampling the release as it goes along. These will likely be torrent only releases. Additionally snapshot releases can be attempted weekly after the Beta has been released. This could give developers a target for getting important bugs fixed or changes in if they know a snapshot is coming up. If the compose fails we just try again next week.

Alpha

The Alpha release would mostly be used as a starting platform for somebody wanting to develop a feature for the given release. It would have many of the post-release updates done to the previous release plus some start of new features for the current release. Mostly what the project cares about this release is that it is installable and can get updates after the fact. As such we don't necessarily need community wide testing of the tree leading up to the Alpha release. Thus we won't block rawhide and instead use a freeze tag within Koji to compose the release from and keep rawhide composing from the unfrozen collection tag. This Alpha release should happen at near the current "Test1" time frame.

Beta

The Beta release would target the same time frame as our previous "Test 2" releases. This release would signify a few key things. The Feature Freeze and the String Freeze happen at this point as well. Since we need the new features to be at least testable at this point it would be good to have more eyes on the packages that will be in the beta release. For that reason we will actually do a blocking freeze at this point. Rawhide will compose from the freeze tag up until the point in which we have a "gold" set of packages for the Beta release.

Early (optional) CVS branching

Right after Beta release or sometime between Beta and RC release, we allow for early branching of software. This allows developers to check in new features and otherwise unstable changes that would not be suitable to introduce to the current release.

Release Candidate and Final release

In order to prepare the release candidate(s) and the final release a final freeze is needed. It is at this point that we would block rawhide once again. It is extremely important that we have as many eyes on the bits as possible to make our release as best as we can. This freeze point is also the point in which we would create any remaining needed branches in CVS for the release. Any builds from the branch would be held in an updates candidate tag to be potential updates for after the release, or to be pulled in to the release by request. Builds from devel/ would be tagged for the next release tag to show up in rawhide once the next development cycle starts. In order to accommodate a release candidate set plus the final release creation the freeze point for this should happen between the current Test3 dates and the final deep freeze dates.

This freeze point is also the point in which we would create any remaining needed branches in CVS (that haven't been created during the early CVS branching) for the release.

Example Schedule

To illustrate what this would mean to the schedule, here is a mock up of what the Fedora 9 schedule would look like.

Note that this doesn't take into account any holidays or other product schedules, this is just purely a work backwards from a target release date of May 1st. Freeze dates and dates for branching/pre-branching are all made up on the spot just to illustrate how a release process could work, not to be taken as actual dates.

8 Nov 2008	F8 Release
8 Nov 2008	F9 Planning Begins (Features considered for approval)
17 Jan 2008	F9 Alpha release
4 March 2008	F9 Beta freeze
4 March 2008	F9 Planning Ends (No new Features considered)
4 March 2008	F9 FEATURE freeze
4 March 2008	F9 string freeze
13 March 2008	F9 Beta release
13 March 2008	Allow F-9 pre-branch
1 April 2008	F9 translation freeze
8 April 2008	Final Development freeze
8 April 2008	Branch all packages for F-9
17 April 2008	Release Candidate 1
1 May 2008	F9 final release

To view a detailed time-line and other renditions, start by going here . Or download a gantt chart version here

Affected Parties

Pretty much all developers and consumers of Fedora would be affected by this change. Engineering schedules will need to be adjusted for the new freezes and dates, IS/IT/Mirrors would need to adjust their expectations for incoming bits, QA needs to adjust it's schedule and plans for the new model, users need to adjust their expectation of bits to test, etc etc etc... Since this change is so global it will need to be communicated very loudly, very clearly, and very early in the Fedora 9 cycle.

Documentation Changes

Much documentation would need to be changed. As part of acceptance of this proposal a running list will begin of packages that will need to be changed for the new policy. Also any external documentation sources that are discovered should also be listed, along with contact information, so that they can be properly notified when the new policy goes into effect.

Wiki Changes

• ReleaseEngineering/Overview
• ReleaseEngineering/TestFreezePolicy

Summary

To summarize the actual changes that developers would face are:

• Decreased frozen rawhide time
• Ability to work on next release items sooner
• Meaningful date driven (pre)release targets
• Less hoops to jump through to get builds into a release
• Predictable snapshot builds to target

Discussion

Questions or comments regarding this proposed change should be directed to the fedora-devel-list mailing list. The ReleaseEngineering team is driving this proposal.