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?