(Translated by https://www.hiragana.jp/)
Schedule :: Fedora Docs

Schedule

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 accommodate travel for Flock and DevConf.CZ, which often fall near the start of the mass rebuild.

Smartsheet

The schedule lives in Smartsheet (only available to Red Hat employees). 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-2 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 Early 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 f-N directory in the schedule repository 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

Git repo

The files used to publish the scripts live in a git repository.

To create a schedule for a new version (f-30 in this example):

  1. mkdir f-30

  2. cp ../f-29/Makefile . && vi Makefile # copy forward from previous and change the version

  3. Export the XML file (see previous section)

  4. git add Fedora.Schedule.xml Makefile

  5. git commit -m ‘Your commit message here’

  6. to see the changes locally: make # make clean cleans up your mess

  7. make publish # publish html and friends to fedorapeople

The rsync invocations in the Makefile assume you have your user name set in ~/.ssh/config if your local name does not match your Fedora account.

To update the index page of the website, or the CSS file used to style it, start from the schedule repo above:

  1. cd html

  2. Edit the appropriate file

  3. make publish to rsync to fedorapeople

  4. Commit and push your edits

Product Pages

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

To register a new version 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

  6. Click Schedules tab

  7. Click Add schedules button

  8. Handle: <get the Smartsheet file URL or ID>

  9. Switch draft to approved

  10. Set phase to planning

Prior to May 2021, we used a Red Hat CVS server for the schedule files. They now are pulled directly into Product Pages from Smartsheet.

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.

Want to help? Learn how to contribute to Fedora Docs ›