Fedora Activity Day Fedora Development Cycle 2009

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Budget)
m (added header)
 
(23 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Draft}}
+
{{header|events}}
  
 
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 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 [[How_to_organize_a_FAD | 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 small number of specific contributors will be funded and brought into this event.  Funding for [[FAD]] events [[How_to_organize_a_FAD | 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 ==
 
== FAD Fedora Development Cycle Details ==
 
This is tentative details, still in planning.
 
This is tentative details, still in planning.
 
* Dates: Monday, June 8, 2009 through Wednesday, June 10, 2009  
 
* Dates: Monday, June 8, 2009 through Wednesday, June 10, 2009  
* Place: [http://maps.google.com/maps?cid=12098330938032168429&gl=us&hl=en Red Hat, Inc.] -- Raleigh Headquarters, 1801 Varsity Drive, Raleigh, NC 27606 (or maybe Venture III building)
+
* Place: [http://maps.google.com/maps?cid=12098330938032168429&gl=us&hl=en Red Hat, Inc.] -- Raleigh Headquarters (Venture III Building), 900 Main Campus Drive, Raleigh, NC 27606
* Room: To be determined
+
* Room: Augusta National
 
* Time: 9 a.m. to 4:30 p.m.
 
* Time: 9 a.m. to 4:30 p.m.
 +
* Dial-in: [http://talk.fedoraproject.org/ Fedora Talk], extension 2005
 +
* VoIP: sip:2005@fedoraproject.org
 +
* IRC: #fad on Freenode IRC Network
 +
* Gobby: gobby.fedoraproject.org - http://fedoraproject.org/wiki/Communicate/GobbyHowTo
 +
{{admon/important | Please mute your phone | If you dial in using phone or VoIP, '''please''' mute your line, and use IRC to send feedback and questions. The on-site participants will monitor IRC and relay questions to the conference as needed.}}
  
 
== Activities ==
 
== Activities ==
  
 
* Design thinking session regarding Fedora development cycle ''(see schedule below for details)''
 
* 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 ===
 
=== Schedule ===
  
Day 1:
+
==== Day 1 ====
 
{|tableclass="t1"
 
{|tableclass="t1"
 
|-
 
|-
Line 33: Line 49:
 
|align="left" | 12:00pm ||align="center" | Lunch
 
|align="left" | 12:00pm ||align="center" | Lunch
 
|-
 
|-
|align="left" | 1:30pm ||align="center" | Continued Ideate
+
|align="left" | 1:30pm ||align="center" | Continued Ideate and Research
|-
+
|align="left" | 2:30pm ||align="center" | Prototype - Combine, Expand, and Refine ideas
+
 
|-
 
|-
 
|align="left" | 4:30pm ||align="center" | Wrap-up / Personal Time - Catch up on email/etc.. plan the evening.
 
|align="left" | 4:30pm ||align="center" | Wrap-up / Personal Time - Catch up on email/etc.. plan the evening.
|-
 
|align="left" | 6:00pm ||align="center¨ | Dinner?
 
 
|}
 
|}
  
Day 2:
+
''Delayed: Prototype - Combine, Expand, and Redefine ideas''
 +
 
 +
'''Log:''' [http://pfrields.fedorapeople.org/documents/fad-rdu/fad-devel-rdu-20090608.txt ASCII text (11.3 KB)]
 +
 
 +
==== Day 2 ====
 
{|tableclass="t1"
 
{|tableclass="t1"
 
|-
 
|-
Line 58: Line 74:
 
|-
 
|-
 
|align="left" | 4:30pm ||align="center" | Wrap-up / Personal Time - Catch up on email/etc.. plan the evening.
 
|align="left" | 4:30pm ||align="center" | Wrap-up / Personal Time - Catch up on email/etc.. plan the evening.
|-
 
|align="left" | 6:00pm ||align="center¨ | Dinner?
 
 
|}
 
|}
  
Day 3:
+
'''Log:''' [http://notting.fedorapeople.org/fad-devel-rdu-20090609.txt ASCII text (9.4 KB)]
 +
 
 +
==== Day 3 ====
 
{|tableclass="t1"
 
{|tableclass="t1"
 
|-
 
|-
Line 72: Line 88:
 
|-
 
|-
 
|align="left" | 12:00pm ||align="center" | Lunch
 
|align="left" | 12:00pm ||align="center" | Lunch
|-
 
|align="left" | 1:30pm ||align="center" | Social Event?
 
 
|-
 
|-
 
|align="left" | 4:30pm ||align="center" | Wrap-up / Personal Time - Catch up on email/etc.. flights home.
 
|align="left" | 4:30pm ||align="center" | Wrap-up / Personal Time - Catch up on email/etc.. flights home.
 
|}
 
|}
 +
 +
'''Log:''' [http://pfrields.fedorapeople.org/documents/fad-rdu/fad-devel-rdu-20090610.txt ASCII text (1.6 KB)]
  
 
== Attendees ==
 
== Attendees ==
Line 89: Line 105:
 
* [[User:jwboyer|Josh Boyer]]
 
* [[User:jwboyer|Josh Boyer]]
 
* [[User:Pfrields|Paul W. Frields]]
 
* [[User:Pfrields|Paul W. Frields]]
 +
* [[User:Rdieter|Rex Dieter]]
 +
* [[User:StevenParrish| Steven Parrish]]
 +
* [[User:linville|John W. Linville]]
  
== Tavel ==
+
== 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.
 
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 will be procured for transport during the event.
+
A rental van may be procured for transport during the event.
  
 
Hotel will likely be the [http://www.lq.com/lq/properties/propertyProfile.do?ident=LQ966&propId=966 La Quinta Inn & Suites] in Cary, near the RHT office.  Attendees will be doubled up in rooms.
 
Hotel will likely be the [http://www.lq.com/lq/properties/propertyProfile.do?ident=LQ966&propId=966 La Quinta Inn & Suites] in Cary, near the RHT office.  Attendees will be doubled up in rooms.
Line 101: Line 120:
  
 
Other meals will not be paid.
 
Other meals will not be paid.
 
== Social Event ==
 
Time and budget permitting, a social event would be nice.  Ideas welcome.
 
  
 
== Budget ==
 
== Budget ==
Line 111: Line 127:
 
* Transportation to/from airport/hotel/office/food
 
* Transportation to/from airport/hotel/office/food
  
 +
== Background ==
 +
 +
The email that started this all was sent by [[User:jkeating|Jesse Keating]] on May 14.  It is included here for full disclosure.
 +
 +
<pre>
 +
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?
 +
</pre>
 +
 +
== Resulting Output ==
 +
These proposals came from the work done at this FAD:
 +
 +
* [[Milestone_Adjustment_Proposal]]
 +
* [[Israwhidebroken.com_Proposal]]
 +
* [[Koji_Build_Autosign_Proposal]]
 +
* [[Critical_Path_Packages_Proposal]]
 +
* [[No_Frozen_Rawhide_Proposal]]
  
 +
[[Category:Events]]
 
[[Category:Events 2009]]
 
[[Category:Events 2009]]
 
[[Category:FAD]]
 
[[Category:FAD]]

Latest revision as of 08:12, 19 August 2010

FedoraEvents Header EventN1.png


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.

Contents

[edit] 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 (Venture III Building), 900 Main Campus Drive, Raleigh, NC 27606
  • Room: Augusta National
  • Time: 9 a.m. to 4:30 p.m.
  • Dial-in: Fedora Talk, extension 2005
  • VoIP: sip:2005@fedoraproject.org
  • IRC: #fad on Freenode IRC Network
  • Gobby: gobby.fedoraproject.org - http://fedoraproject.org/wiki/Communicate/GobbyHowTo
Important.png
Please mute your phone
If you dial in using phone or VoIP, please mute your line, and use IRC to send feedback and questions. The on-site participants will monitor IRC and relay questions to the conference as needed.

[edit] 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?

[edit] Schedule

[edit] 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 and Research
4:30pm Wrap-up / Personal Time - Catch up on email/etc.. plan the evening.

Delayed: Prototype - Combine, Expand, and Redefine ideas

Log: ASCII text (11.3 KB)

[edit] 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.

Log: ASCII text (9.4 KB)

[edit] 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.

Log: ASCII text (1.6 KB)

[edit] Attendees

[edit] 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.

[edit] Food

Hotel provides breakfast.

Other meals will not be paid.

[edit] Budget

Fedora Budget for certain attendees will be used for:

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

[edit] 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?

[edit] Resulting Output

These proposals came from the work done at this FAD: