Developing and maintaining the Fedora Project’s schedule may be the most important part of the Fedora Program Manager’s job. The good news is that it is not very hard. FESCo approved reusing the same general structure for every release, with target release dates of the third Tuesday in April and October. Now it will only change if there are major requirements that necessitate a deviation. This helps with planning for Fedora as well as for our downstreams (read: RHEL).

Of course, you can—and should—make small changes to the schedule as processes evolve. This may mean adding, removing, or moving some tasks. Or it might mean changing which teams are reflecting in the web view of the schedule.

FESCo authorized Release Engineering to start the mass rebuild up to five days after the scheduled start date. This allows RelEng to accomodate travel for Flock and DevConf.CZ, which often fall near the start of the mass rebuild.


The schedule lives in Smartsheet. Every so often, go in and copy a few releases forward.

In your new schedule:

  • Update the “Fedora XX Release”

  • Find and replace N-1 with N (have to do it manually so as to not get dates)

  • Find and replace N-3 with N-1 (same)

Tasks are assigned to teams with flags. The pp flag has no meaning for the community, but is used to keep in sync with other Red Hat products. Some fields (e.g. requirements gathering) are not relevant, but required for Product Pages. Product Pages only cares about the key flag.

If you want links in the schedule, add the URL in the “links” column for that task (the Link: keyword is optional now). It will be shown in the rendered schedule.

The Preferred Final target date is the “master milestone” against which everything else is anchored.

Before publishing the schedule, check to be sure that it doesn’t conflict too horribly with major holidays, etc.

To publish the schedule, Export to Microsoft Project (XML) and save the file to the CVS f-N directory as Fedora.Schedule.xml.

If Export to Microsoft Project (XML) is not an option, you might need to switch to Gantt view. Smartsheet isn’t very smart in that regard.

When schedules slip:

  1. Add a new target date (e.g. Beta target date #2)

  2. Update the “Current X target date” when you know it’s really going to happen

CVS repo

Red Hat product schedules are kept in a CVS repository. See the internal documentation for instructions on setting up your machine. Check out the repo and go to program/fedora, which has schedules back through Fedora Core 5.

To create a schedule for a new version: 1. mkdir f-30 2. cvs add f-30 3. vi Makefile # copy forward from previous and change the version 4. Export the XML file (see previous section) 5. cvs add Fedora.Schedule.xml Makefile 6. cvs ci -m ‘Your commit message here’ 7. to see the changes locally: make (make clean cleans up your mess) 8. # fedora/common/Makefile.common has settings for rsyncing 9. make publish #publish html and friends to fedorapeople 10. Product Pages automatically picks up when you check in to CVS

Product Pages

Product Pages is the central resource for Red Hat product schedule and status information.

To register a new verison in product pages:

1.Go to admin page (Platforms > Fedora Project > Overview) 2. Click Add new release button 3. Short name: 30 4. Select all the sections to copy 5. Click OK 7. Click Schedules tab 8. Click Add schedules butotn 9. Handle: <find the file in the browser> 10. Switch draft to approved 11. Set phase to planning

Use the xml file instead of directly using Smartsheet so you get version history.

Key fields:

  • Platforms: if you want to update it, add the list of platforms Fedora supports (used by RH releng, but Fedora releng doesn’t use it. so it’s entirely optional)

  • Documents: just make a link to the wiki

  • People: update this as appropriate

  • Communication: list of important IRC channels and mailing lists

Status updates

Update the phases when there’s a significant change (e.g. Beta release → change to testing).

Update the status on a weekly basis (due Thursday afternoon US East coast time). Green means no risks and no slippage; you don’t need to say much. Yellow means there are risks, but we have it under control. Describe what went wrong and how we’re going to address it. Red means "oh noes!"; explain a lot more.

Historical notes

This section is a collection of loosely-organized facts that give some of the history of schedule wrangling.

  • Schedules used to be done with TaskJuggler (version 2, specifically). If you ever need to do anything with the old schedule files, you will need to get a copy of that. (By the time you read this, it will likely be retired from Fedora.)

  • We used to copy key milestones to a wiki page. Ben Cotton stopped doing that because it was annoying and he’s error-prone.