operations/docs
operations/docs
4
2
Fork 11
Code Issues 3 Pull requests 1 Activity Actions

Add the schedule docs

Browse source
This commit is contained in:
Ben Cotton 2019-10-03 14:43:31 -04:00
commit 43bcfacb54
1 changed files with 108 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

108
modules/pgm_guide/pages/schedule.adoc Normal file
View file

@ -0,0 +1,108 @@
= Schedule
Developing and maintaining the https://fedorapeople.org/groups/schedule/[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.
https://pagure.io/fesco/issue/2211#comment-590831[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 https://fedorapeople.org/groups/schedule/[web view] of the schedule.
== Smartsheet
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 xref:_product_pages[Product Pages].
Product Pages only cares about the *key* flag.
TIP: 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.
TIP: 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`.
TIP: 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 https://docs.engineering.redhat.com/display/EPM/CVS+schedule+storage+local+setup[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
https://pp.engineering.redhat.com/[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
TIP: 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.