From f8d57f6b10051b91e41877dcc7fea90e22c3b8c9 Mon Sep 17 00:00:00 2001 From: Ben Cotton Date: Wed, 2 Oct 2019 17:15:03 -0400 Subject: [PATCH] Add the procedure for Change wrangling --- modules/pgm_guide/pages/changes.adoc | 78 ++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 modules/pgm_guide/pages/changes.adoc diff --git a/modules/pgm_guide/pages/changes.adoc b/modules/pgm_guide/pages/changes.adoc new file mode 100644 index 0000000..57d1cdc --- /dev/null +++ b/modules/pgm_guide/pages/changes.adoc @@ -0,0 +1,78 @@ += Changes Process +Fedora's Change Process is important to coordinate the development of the next Fedora release. +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, see the https://fedoraproject.org/wiki/Changes/Policy[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 https://fedoraproject.org/wiki/Changes/Policy[Changes Policy] with the https://docs.fedoraproject.org/en-US/fesco/[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 https://pagure.io/fesco/new_issue[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 xref:_tracking[tracking] section) +*** award the Change Accepted https://badges.fedoraproject.org[badge] +** if Change is denied, set category to `ChangePageIncomplete` +** if FESCo asks for clarification or more details, work with Change owner on updates + +TIP: 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 https://pagure.io/fedora-pgm/change-management[change-management repo] to create Bugzilla bugs. + +1. Run `make version= 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 https://pagure.io/fedora-docs/release-notes/new_issue[Release Notes tracker] and add that URL to the wiki page in the *Current Status* section + +WARNING: 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. + +TIP: The Bugzilla API will reject email addresses that don't exist in Bugzilla. +If issue creation fails, that's probably the cause. + +==== 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 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 https://pagure.io/fesco/new_issue[FESCo ticket] with Changes that did not meet required status. +See https://pagure.io/fesco/issue/2218[FESCo #2218] for an example. + +WARNING: 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.