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

Add the procedure for Change wrangling

Browse source
This commit is contained in:
Ben Cotton 2019-10-02 17:15:03 -04:00
commit f8d57f6b10
1 changed files with 78 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

78
modules/pgm_guide/pages/changes.adoc Normal file
View file

@ -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=<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 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.