Changes SOP

This document describes the process of handling Changes.

Timing/trigger

This process is constant.

Process

Announce proposals

This section is not yet written.

Submit proposals to FESCo

This section is not yet written.

Process approved proposals

This section is not yet written.

Process rejected proposals

This section is not yet written.

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

This section is not yet written.