From Fedora Project Wiki

(Created page with '{{subst:Proposal}}')
 
No edit summary
Line 2: Line 2:


== Overview ==
== Overview ==
Always keep rawhide moving forward, never stopping the train.  At branch point, publish the release to be in a different path to allow rawhide to race forward toward the next release.


=== Problem Space ===
=== Problem Space ===
<!-- Describe the problem this proposal seeks to solve -->
<!-- Describe the problem this proposal seeks to solve -->
Currently we spend a lot of time blocking the progress of rawhide.  We
do this to try to get people to test the packages we're targeting for a
release, instead of the packages in the ever rolling development tree that is rawhide.  We get a lot of anger and naval gazing
particularly near the end of a release cycle where things are building
up in the next rawhide tag and in the updates tag for the release we're
about to make.  We then have a flood of pent up changes that hit nearly
all at once, breaking god knows what.
We also tell folks that a development cycle of Fedora starts from the branch point of the release to be and goes all the way to the release of the next release, eg F12 development cycle started at F11 Beta (where we allowed pre-branching) and will last until F12 Feature Freeze.  However by not publishing the builds done for F12 during the F11 Beta/PR/RC phases, little meaningful testing and development could be done for Fedora 12.


=== Proposed Solution ===
=== Proposed Solution ===
<!-- Describe proposed solution in detail -->
<!-- Describe proposed solution in detail -->
To keep rawhide (nearly) always moving, we'll have to change how we do
freezes, particularly the long final development freeze.  Without getting too
much into detail, when we reach feature freeze, and offer pre-branch capability,
we turn that into a full branch event.  devel/ continues to publish to
pub/fedora/linux/development and the train moves on.  Somewhere else on
the mirror we start dumping the builds from the release branch, say F-12
branch.
For a period of time the builds can go directly live each night
until we freeze again.  At the freeze point, bodhi would be used to manage
freeze break requests.  Builds would go into a -candidate tag, bodhi
requests would push them out to a -testing dir for public consumption.
Karma alone or karma + releng/qa approval would promote things from
testing into the directory yet unnamed that is the "rawhide" of the
pending release, until we reach gold/RC/whatever and things that make it
out of -testing go to -updates as 0-day items.


=== Scope ===
=== Scope ===
<!-- Describe the scope of any project work or properties that will be affected by the proposal -->
<!-- Describe the scope of any project work or properties that will be affected by the proposal -->
* compose tools
* Wiki Pages
* Bodhi
* Mirror Layout
* package management repo configs
* bugzilla


=== Active Ingredients ===
==== Compose Tools ====
<!-- A list of any prerequisites or other materials needed to implement the solution -->
Compose tools will need to get a lot faster in order to handle composing rawhide, the pending release to be, potential updates to the pending release to be, and updates to our existing releases, all within the same day.


==== Component 1 ====
==== Bodhi ====
<!-- The first of a list of prerequisites, and what exactly needs to be done with it -->
<!-- The first of a list of prerequisites, and what exactly needs to be done with it -->
Bodhi will have to open early to allow maintainers to request freeze breaks for the pending release. 
Bodhi will also have to be modified so that it can do tagging only "pushes" and allow the nightly compose scripts to compose from the koji tags that bodhi populates.
Bodhi will have to distinguish between a freeze break to go into the release vs an update request which may go out as a 0-day update.
==== Mirror Layout ====
A new set of directories will need to be made to hold the pending release content, as well as candidate freeze breaks for the pending release.
==== package management repo configs ====
Repo configs will need to be changed to reflect the new mirror paths.
==== Wiki Pages ====
Many wiki pages will have to be changed.  This should be an ongoing list of wiki pages that reference the development cycle.


==== Component 2 ====
==== Bugzilla ====
<!-- The second of a list of prerequisites, and what exactly needs to be done with it. Add more subsections as needed for additional components. -->
Bugzilla will need to grow a version earlier in the development cycle so that bugs can be filed for the pending release vs rawhide.


== Discussion Points ==
== Discussion Points ==
<!-- Describe things which should be discussed regarding the proposal.  Specifics that need narrowing down, or contentions parts of the proposal. -->
<!-- Describe things which should be discussed regarding the proposal.  Specifics that need narrowing down, or contentions parts of the proposal. -->
* When do we branch?  Feature Freeze?
* How are buildroot overrides handled, freeze break needs vs 0-day update needs
* Increased number of "double" commits (things committed to rawhide, and duplicated on the release branch)
* Relies on updates-testing to drive feedback for freeze breaks, and updates-testing is not as well used as it could be.
* Division of our testers between rawhide and the pending release
* Are we now Debian (Unstable, testing, stable)
* Potential to break chain-builds even more depending on when we force things through bodhi
* Do we always make install images for rawhide, or only during the time that rawhide is the only nightly tree and hasn't branched yet?
* packages going "straight to stable" via bodhi during a freeze


== Comments? ==
== Comments? ==
Line 29: Line 85:


[[Category:Proposals]]
[[Category:Proposals]]
[[Category:FAD]]

Revision as of 15:12, 10 June 2009


Overview

Always keep rawhide moving forward, never stopping the train. At branch point, publish the release to be in a different path to allow rawhide to race forward toward the next release.

Problem Space

Currently we spend a lot of time blocking the progress of rawhide. We do this to try to get people to test the packages we're targeting for a release, instead of the packages in the ever rolling development tree that is rawhide. We get a lot of anger and naval gazing particularly near the end of a release cycle where things are building up in the next rawhide tag and in the updates tag for the release we're about to make. We then have a flood of pent up changes that hit nearly all at once, breaking god knows what.

We also tell folks that a development cycle of Fedora starts from the branch point of the release to be and goes all the way to the release of the next release, eg F12 development cycle started at F11 Beta (where we allowed pre-branching) and will last until F12 Feature Freeze. However by not publishing the builds done for F12 during the F11 Beta/PR/RC phases, little meaningful testing and development could be done for Fedora 12.


Proposed Solution

To keep rawhide (nearly) always moving, we'll have to change how we do freezes, particularly the long final development freeze. Without getting too much into detail, when we reach feature freeze, and offer pre-branch capability, we turn that into a full branch event. devel/ continues to publish to pub/fedora/linux/development and the train moves on. Somewhere else on the mirror we start dumping the builds from the release branch, say F-12 branch.

For a period of time the builds can go directly live each night until we freeze again. At the freeze point, bodhi would be used to manage freeze break requests. Builds would go into a -candidate tag, bodhi requests would push them out to a -testing dir for public consumption. Karma alone or karma + releng/qa approval would promote things from testing into the directory yet unnamed that is the "rawhide" of the pending release, until we reach gold/RC/whatever and things that make it out of -testing go to -updates as 0-day items.

Scope

  • compose tools
  • Wiki Pages
  • Bodhi
  • Mirror Layout
  • package management repo configs
  • bugzilla

Compose Tools

Compose tools will need to get a lot faster in order to handle composing rawhide, the pending release to be, potential updates to the pending release to be, and updates to our existing releases, all within the same day.

Bodhi

Bodhi will have to open early to allow maintainers to request freeze breaks for the pending release.

Bodhi will also have to be modified so that it can do tagging only "pushes" and allow the nightly compose scripts to compose from the koji tags that bodhi populates.

Bodhi will have to distinguish between a freeze break to go into the release vs an update request which may go out as a 0-day update.

Mirror Layout

A new set of directories will need to be made to hold the pending release content, as well as candidate freeze breaks for the pending release.

package management repo configs

Repo configs will need to be changed to reflect the new mirror paths.

Wiki Pages

Many wiki pages will have to be changed. This should be an ongoing list of wiki pages that reference the development cycle.

Bugzilla

Bugzilla will need to grow a version earlier in the development cycle so that bugs can be filed for the pending release vs rawhide.

Discussion Points

  • When do we branch? Feature Freeze?
  • How are buildroot overrides handled, freeze break needs vs 0-day update needs
  • Increased number of "double" commits (things committed to rawhide, and duplicated on the release branch)
  • Relies on updates-testing to drive feedback for freeze breaks, and updates-testing is not as well used as it could be.
  • Division of our testers between rawhide and the pending release
  • Are we now Debian (Unstable, testing, stable)
  • Potential to break chain-builds even more depending on when we force things through bodhi
  • Do we always make install images for rawhide, or only during the time that rawhide is the only nightly tree and hasn't branched yet?
  • packages going "straight to stable" via bodhi during a freeze

Comments?

To leave a comment, use the Talk page for this proposal.