Changes SOP

This document describes the process of handling Changes.

Timing/trigger

This process is constant.

Process

Announce proposals

Proposals are sent to the development community for public comment.

  1. Verify that the proposal is complete and correct

    1. You can choose to announce proposals that are missing some required fields (e.g. Releng ticket), on the condition that those are complete before it is sent to FESCo

    2. Ensure the page has the {{Change_Proposal_Banner}} macro at the top

    3. Put the Owner and Email fields are one line instead of multiple. This will make the BZ creation easier later.

  2. Compose an email as follows.

    1. Set the to: field to devel-announce@lists.fedoraproject.org

    2. Set the cc: field to devel@lists.fedoraproject.org

    3. Set the subject to F<NN> proposal: <title> (<System-Wide|Self-Contained> Change proposal). This is to make it clear to external readers that this is a proposal and not a final decision.

    4. In the body of the email, add the URL to the wiki page

    5. Copy the "this is a propsal" content from the wiki page into the body. Again, this is so that it’s unambigiously clear.

    6. Copy the wiki source into the body, removing comments and performing other readability cleanup as you deem necessary.

  3. Send the email

  4. Update the wiki page

    1. Replace the ChangeReadyForWrangler category with ChangeAnnounced

    2. Add a link to the devel thread in the Current status section, above the FESCo issue field

  5. Add an entry to the Changes table for the release in Friday’s Fedora Facts

Once you have sent the email, you do not need to further participate in the discussion. However, you should at least monitor the tone in case it gets heated.

You can use the pending_changes.py script to list proposals that are awaiting announcement. This is particularly helpful if you set it up in a cron job or systemd timer.

Submit proposals to FESCo

After a week of discussion (or longer if the discussion is still productively active), submit it to FESCo for approval.

  1. Open an issue with the Change proposal template

    1. Use Change: <title> as the issue title

    2. Replace the angle bracketed fields as appropriate

    3. Set the Assignee of the issue to be the first person listed on the proposal

    4. Set the system-wide change or self-contained change tag as appropriate

    5. Set the Milestone as appropriate

  2. In the proposal wiki page

    1. Replace the ChangeAnnounced category with ChangeReadyForFesco

    2. Add the FESCo ticket URL in the Current status section

  3. Update the Friday’s Fedora Facts entry

Process approved proposals

After a proposal has passed according to FESCo’s ticket policy

  1. Note the vote (e.g. "APPROVED (+6,0,-0)") in the comment, if not already recorded

  2. Apply the pending announcement label if the issue is still open. This lets the next meeting chair know to include an announcement of the decision in the agenda

  3. Edit the proposal’s wiki page

    1. Remove the {{Change_Proposal_Banner}} macro

    2. Replace the ChangeReadyForFesco category with ChangeAcceptedF<NN>

  4. Create new bugs with the scripts

    1. Run make version=<NN> type=<SystemWide|SelfContained> build to download and parse the wiki pages

    2. Run make bz to create tracking bugs in Bugzilla. (See warning below for failure cases)

  5. Edit the created bug

    1. Set the assignee to the first person listed on the Change page

    2. Add yourself to the cc field

    3. Set the bug to block the F<NN>Changes tracking bug

    4. Set the bug status to ASSIGNED

  6. Create a Release Notes issue with the Change template.

    1. Use Change: <title> as the issue title

    2. Replace URL HERE with the wiki URL

    3. Set the Milestone appropriately

  7. Update the Friday’s Fedora Facts entry

  8. Update the ChangeSet page

Bugzilla requires an email address to exist in the system in order to add it to a bug. If an email address listed on a wiki page does not exist in Bugzilla, you will have to update the feature-pages.csv file with the correct address (or remove it and add it later.) If you are processing multiple newly-approved proposals at once, re-running the script after correcting the email address may lead to duplicate bugs. Remove Changes with successful bug creation from feature-pages.csv or finish the above steps for the successful bugs before starting over with the failed bugs.

Process rejected proposals

If a Change proposal is rejected by FESCo:

  1. Add {{Change_Rejected_Banner}} to the proposal’s wiki page below the title

  2. Update the wiki page category to Category:ChangePageIncomplete

  3. If a tracking bug was pre-created, close it with Status CLOSED → DEFERRED.

Evaluate contingency plans

The start of the mass rebuild and branch day are also common times for contingency dates, so you should go through those at those times, as well.

Report incomplete Changes

This part of the process runs at the "Completion deadline (testable)" and "Completion deadline (100% complete)" milestones of the release schedule.

  1. On the deadline day, search for bugs that block the Changes tracking bug that do are not at least as far as MODIFIED (testable deadline) or ON_QA (100% complete deadline).

  2. Mass update those bugs with a comment (templates below) and set NEEDINFO on the assignee.

  3. The next day, create a FESCo issue using one of the FESCo issue templates below. You may choose to try to figure out if a change is complete yourself, but you are not obligated to.

  4. Continue to update the FESCo issue as bugs are updated.

  5. Update or defer Changes as voted by FESCo.


Bug update comment (testable)

Today we reached the Code Complete (Testable) milestone on the F<VERSION> schedule: <SCHEDULE LINK>

At this time, all F<VERSION> Changes should be complete enough to be testable. You can indicate this by setting this tracker to the MODIFIED status. If the Change is 100% code complete, you can set the tracker to ON_QA. If you need to defer this Change to F<NEXT RELEASE>, please NEEDINFO me.

Changes that have not reached at least the MODIFIED status will be given to FESCo for evaluation of contingency plans.

Bug update comment (100% complete)

Today we reached the Code Complete (100% complete) milestone on the F<VERSION> schedule: <SCHEDULE LINK>

At this time, all F<VERSION> Changes should be 100% complete. You can indicate this by setting this tracker to the ON_QA status. If you need to defer this Change to F<NEXT RELEASE> please NEEDINFO me.

Note that we are entering the Beta freeze. Additional package changes to complete this Change will need an approved blocker or freeze exception. See pass:[https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process] and pass:[https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process] for more information.

Changes that have not reached the ON_QA status will be given to FESCo for evaluation of contingency plans.

Completion deadline (testable) FESCo issue template

On Tuesday, <DATE> we reached the Change Checkpoint: Completion deadline (testable). At this milestone all the F<VERSION> Changes should be testable, which is indicated by "MODIFIED" status of a tracking bug. A [Bugzilla query](pass:[https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&f1=blocked&list_id=12817824&o1=substring&v1=F<VERSION>Changes]) shows all the tracking bugs which are not in "MODIFIED" state and are not considered testable. System-Wide Changes with the contingency date in bold are past the stated contingency date.

These changes are presented for FESCo review to determine what action, if any, should be taken. The next deadline is <DATE> when all changes should be 100% code complete.

## System-Wide Changes

* [<Change title>](<Wiki URL>)
    * Owner: @<ID>
    * Contingency mechanism: <mechanism>
    * Contingency deadline: <deadline>
* <repeat as necessary>

## Self-Contained Changes

* [<Change title>](<Wiki URL>)
    * Owner: @<ID>
* <repeat as necessary>

Completion deadline (100% complete) FESCo issue template

On Tuesday, <DATE> we reached the Change Checkpoint: Completion deadline (100% complete). At this milestone all the F<VERSION> Changes should be fully complete, which is indicated by "ON_QA" status of a tracking bug. A [Bugzilla query](pass:[https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&f1=blocked&list_id=12817824&o1=substring&v1=F<VERSION>Changes]) shows all the tracking bugs which are not in "ON_QA" state and are not considered complete. System-Wide Changes with the contingency date in bold are past the stated contingency date.

These changes are presented for FESCo review to determine what action, if any, should be taken.

## System-Wide Changes

* [<Change title>](<Wiki URL>)
    * Owner: @<ID>
    * Contingency mechanism: <mechanism>
    * Contingency deadline: <deadline>
* <repeat as necessary>

## Self-Contained Changes

* [<Change title>](<Wiki URL>)
    * Owner: @<ID>
* <repeat as necessary>

Defer Changes

FESCo or the Change owner may decide to defer a change to the next release. This is commonly due to work or dependencies not being complete at a deadline. Unless the Change changes significantly, it does not need to go through the process again.

  1. Reply to the mailing list thread, only if the proposal has not yet been submitted to FESCo.

  2. Update the Milestone in the FESCo ticket, only if the ticket is still open (in other words, if FESCo has not yet reached a decision).

  3. Update the Change’s wiki page. Change the "Targeted Release" to the new release. Change the category to "ChangeAcceptedF<N>".

  4. Update the tracking bug. Update the Blocks field with the new release’s Change tracking bug. If the Change is deferred after bugs have been branched, reset the version to "rawhide".

  5. Update the Release Notes issue. Set the Milestone field to the new target release.

  6. Re-run the Change processing scripts for the old and new target release. See the instructions below.

If the Change was previously approved, do not award the badge for the re-targeted release.

Update ChangeSet page

After processing approved or deferred Changes, and regularly throughout the late part of the release cycle, update the wiki page listing that release’s approved Changes.

  1. Process the status with the scripts

    1. Run make version=<NN> type=<SystemWide|SelfContained> build to download and parse the wiki pages. This includes a check of the current status of the tracker bugs in Bugzilla

  2. Copy the content of the ChangesList file

  3. Paste it into the appropriate section of the Release/F<NN>/ChangeSet page in the wiki