Changes Process

For more details on Change Process, see the Changes Policy.

Responsibilities

The Program Manager’s 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. The Program Manager works on the Changes Policy with the Fedora Engineering Steering Committee (FESCo), Working Groups and other Fedora teams and bodies (documentation, marketing, etc.).

SOP

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

Submission

Change submission is done in the Fedora Project Wiki.

  • 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

  • Each change has to be proposed by Change Owner. Once Change category is set to ChangeReadyForWrangler, 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).

    • If a proposal has missing, incomplete, or confusing information, set the category back to ChangePageIncomplete and email the change owner(s) to let them know what you’re looking for.

  • Once Change page is correct enough, it has to be announced on devel-announce and devel mailing lists.

    • Include the version, type (Self-Contained or System-Wide), and title in the email subject

    • Include the wiki page URL and content of the proposal in the email body

    • Set category to ChangeAnnounced

  • After 7 days, submit the Change proposal for FESCO’s approval. Create a FESCo ticket that includes

    • Version, type, and title in the ticket summary

    • Change summary in the body of the ticket

    • Link to change proposal in the body of the ticket

    • Link to devel-announce and devel threads in the body of the ticket

    • Tag owners in the body of the ticket

  • After FESCo meeting, process Changes queue:

    • if Change is approved

      • set category to ChangeAcceptedFXX, where XX is aimed version

      • create Tracking bug (see tracking section)

      • award the Change Accepted badge

    • if Change is denied, set category to ChangePageIncomplete

    • if FESCo asks for clarification or more details, work with Change owner on updates

Submitting to both mailing lists at the same time will give the threads identical URLs (modulo the list name) in Hyperkitty, which makes adding links to the FESCo ticket easier.

Tracking

Create tracking bug

After a change is accepted, you can use the scripts in the change-management repo to create Bugzilla bugs.

  1. Run make version=<version> type=<type> build to pull the contents of change proposals

  2. Run make bz to create Bugzilla tracking bugs

  3. Edit each bug to:

    • Correct the assignee to the change owner and ensure the CC entries are correct

    • Set the status to ASSIGNED

  4. Add the Bugzilla URL to the wiki page in the Current Status section

  5. Create an issue in the Release Notes tracker and add that URL to the wiki page in the Current Status section

The Bugzilla script isn’t very smart. If you re-run it (e.g. to correct an email address), it will create duplicate bugs for any changes it already processed. Edit the feature-pages.csv file to remove already-processed bugs or run make clean and re-run steps 1 and 2 above.
The Bugzilla API will reject email addresses that don’t exist in Bugzilla. If issue creation fails, that’s probably the cause.

ChangeSet wiki page

Each release has a ChangeSet page (Releases/N/ChangeSet) in the wiki that lists the accepted changes for that release. Step 1 above produces a file called ChangesList that includes the Mediawiki-formatted content you can copy and paste into the appropriate section of the ChangeSet wiki page.

Re-run the make …​ build script and update the wiki page after finishing the steps in the Create tracking bug section and regularly as code completion deadlines approach. This ensures that the page is up-to-date.

Update status

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 the ChangeSet page with step 1 in the tracking bug creation process.

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.

The day after the deadline, open a FESCo ticket with Changes that did not meet required status. See FESCo #2218 for an example.

We don’t have a good way of tracking the contigency deadline for Changes with a contingency plan. This essentially means we trust Change owners to self-enforce. If you want to make life better, come up with a better solution.