Fedora Activity Day Fedora Development Cycle 2009

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

A cross functional team of people will meet and discuss current problems with the Fedora Development Cycle and discuss potential changes to the cycle to solve the problems.

A small number of specific contributors will be funded and brought into this event. Funding for FAD events is very limited so that many events can be held each quarter. All Fedora contributors are welcome to sit in, particularly those greatly impacted by changes to the Fedora Development Cycle. A conference room using Fedora Talk will be set up so that people unable to attend can dial in and participate.

FAD Fedora Development Cycle Details

This is tentative details, still in planning.

• Dates: Monday, June 8, 2009 through Wednesday, June 10, 2009
• Place: Red Hat, Inc. -- Raleigh Headquarters, 1801 Varsity Drive, Raleigh, NC 27606 (or maybe Venture III building)
• Room: To be determined
• Time: 9 a.m. to 4:30 p.m.

Activities

• Design thinking session regarding Fedora development cycle (see schedule below for details)

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 train 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.

What if there was a better way?

Schedule

Day 1:

Time	Activity
9:00am	Kickoff and brief description of Design Thinking
9:30am	Define - Discuss the ongoing issues of Fedora Development Cycle
10:30am	Research - Dig into the history of Fedora Development, what worked, what didn't.
11:00am	Ideate - Brainstorm on potential ways to fix the problems
12:00pm	Lunch
1:30pm	Continued Ideate
2:30pm	Prototype - Combine, Expand, and Refine ideas
4:30pm	Wrap-up / Personal Time - Catch up on email/etc.. plan the evening.

Day 2:

Time	Activity
9:00am	Recap of previous day
9:30am	Choose - Review objectives and vote on potential solutions
10:30am	Implement - Walk through chosen solutions and explore work needed.
12:00pm	Lunch
1:30pm	Continued Implement
4:30pm	Wrap-up / Personal Time - Catch up on email/etc.. plan the evening.

Day 3:

Time	Activity
9:00am	Recap
9:30am	Proposal - Draft proposal on Wiki to shop around to larger audiences
12:00pm	Lunch
4:30pm	Wrap-up / Personal Time - Catch up on email/etc.. flights home.

Attendees

• Jesse Keating
• Bill Nottingham
• Tom Callaway
• James Laska
• Will Woods
• Luke Macken
• Seth Vidal
• Josh Boyer
• Paul W. Frields
• Rex Dieter

Travel

RDU (Raleigh/Durham International) is the local airport. Shuttles to hotels are available, and depending on timing, one of the attendees can pick people up in a rental van.

A rental van may be procured for transport during the event.

Hotel will likely be the La Quinta Inn & Suites in Cary, near the RHT office. Attendees will be doubled up in rooms.

Food

Hotel provides breakfast.

Other meals will not be paid.

Budget

Fedora Budget for certain attendees will be used for:

• Flights
• Hotel
• Transportation to/from airport/hotel/office/food

Background

The email that started this all was sent by Jesse Keating on May 14. It is included here for full disclosure.

From: 	Jesse Keating <jkeating@redhat.com>
To: 	notting@redhat.com, wwoods@redhat.com, jlaska@redhat.com, spot@redhat.com
Subject: 	A different approach to Fedora Development
Date: 	Thu, 14 May 2009 23:10:30 -0700


So I've been kicking something around in my head for the past few days,
and oddly enough it was a "conversation" with Ralf that got this going.

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 train
(failboat) 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.

What if there was a better way?

I've got a rough idea on something, and I've already kicked it around
with Will because it closely matches something he was thinking of as
well.  What I'd like to do is outline it a bit here, to seed the
thought, and try to find some time/budget to get all of us in a room for
a day or 3 with a whiteboard and really go over if this is worth doing,
possible, and what all it would involve.

Basic idea, always keep rawhide moving forward, never stop the train.
pub/fedora/linux/development is the rolling release that is rawhide. It
never stops, it rarely slows down, it just keeps on truckin along.  This
is where we send people that always want the most bleeding edge
software.

To keep rawhide (nearly) always moving, we'll have to change how we do
freezes, particularly the long final devel freeze.  Without getting too
much into detail, when we reach beta, 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 that 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.

What this would accomplish is more clearly demonstrate that the
development cycle for Fedora really goes from Beta to Beta.  After Beta,
we have two streams going, development of the next release via rawhide,
and bugfix + polish of the pending release.  It would also keep the
various outputs of builders ever moving, be it rawhide, or updates of
some kind.  It would unify the interface that developers use to produce
updates, either updates to a stable release, or updates to a pending
frozen release.

There are lots of challenges here, more than I'd like to get into over
email.  But at the basic level, I think we all need to agree that we
need to change something here, and that this is potentially a good
change, something that is worth the cost of putting us all in a room to
brainstorm and work it out.

What do ya'll think?