Fedora Program Management/ChangesSOP

Changes Process

Change Process is important process to coordinate the next Fedora releases. We need to know about disrupting changes coming to the next release to set the scope of release but it also helps as marketing tool even for leaf changes. For more details on Change Process, check Changes Policy.

Responsibilities

FPgM key responsibility is to maintain Changes Process - scheduling, submission, announcements, reporting and tracking. One of the main responsibilities is helping Change owners through the submission process. FPgM works on Changes Policy with FESCo, Working Groups and other Fedora teams and bodies (Documentation, Marketing etc.).

This job is called Changes Wrangler and is usually held by FPgM.

SOP

The SOP consists of two phases. Change submissions and Changes tracking.

Submission

Change submission are mostly done in the Fedora Project Wiki.

• When scheduling release, schedule "Change Checkpoint: Proposal submission deadline (System Wide Changes)" task. At this point, all Changes has to be proposed and properly announced. But for Self Contained Changes, it's not that strict deadline, although it's preferred. See Fedora Release Life Cycle. The time between branch may vary due to delays in previous release.
• Set up infrastructure for Changes on the Fedora Project Wiki (for a new release) - correct categories, ChangeSet page etc.
  • Create Category:ChangeAcceptedFXX, where XX is Fedora version
  • Create Releases/XX/ChangeSet page, where XX is Fedora version
• Announced submission deadline ahead of it
• Each change has to be proposed by Change Owner. Once Change category is set to ChangeReadyForWrangler, Change Wrangler checks formal correctness - all required fields are filled in, right category is set, page structure is correct (important, as scripts are used to parse the document). Also based on previous knowledge of what current FESCo is looking for, advise Change Owner to enhance document. This might be subjective and it's not required to fulfil but may help change approval later.
• Once Change page is correct enough, it has to be announced on devel-announce mailing list. Based on the template provided, announce change on the list by sending email. Set category to ChangeAnnounced. It has to be announced for at least 7 days (but with exceptions in case there's no on-going discussion or time pressure).
• After 7 days, Change is prepared for FESCO's approval. It's advised to create FESCo ticket at least one day before target FESCo meeting, so it's added on the FESCO meeting's agenda.
  • More details to be done...
• After FESCo meeting, process Changes queue:
  • if Change is approved
    • set category to ChangeAcceptedFXX, where XX is aimed version
    • create Tracking bug (script provided)
  • if Change is denies, set category to ChangePageIncomplete
  • if FESCo asks for clarification or more details, work with Change owner on updates

Tracking

Changes progress is tracked in the Change bugs. It's important to know the status especially of System Wide changes to trigger Contingency plan in case of need.

• It's good to take a look on Changes progress periodically and update ChangeSet page (/wiki/Releases/XX/ChangeSet) — HOW?
• Two weeks before each completion milestone, announce it on the devel-announce mailing list and ask Change Owners to report Change status and potential issues. Work with Change Owners during this two weeks to collect status for FESCo. Use mass bug comment feature of Bugzilla.
• Day after the deadline, prepare report for FESCo (as the ticket) with Changes that met or did not meet required status (see Changes Policy for explanation of statuses).
• Act as FESCo decided on the meeting
• Once release is delivered, close bugs as CLOSED:CURRENT_RELEASE