Update.1 process

Process to Approve Changes to Ship.2

The release team will approve tickets and assign to the designated release engineer (for Ship.2, this is cscott).

The bundles/RPMS MUST be present in Joyride for anything not coming from Koji (the Fedora build system). Note that SRPM's for each RPM MUST also be present, and should be updated each time the binary RPM is updated. Activity bundles that are solely Python do not need separate SRPM's; if your activity contains binary code, we expect the source/SRPM's to also be present along with the activity bundle; please discuss with us how to package your sources.

To get approval for bug fixes or some remaining enhancement to actually go into Update.1, use the following process:

there MUST be at least one ticket in Trac, it should already have been marked for resolution in Update.1; it can reference additional tickets to be closed by the commit, and should clearly indicate exactly which bundle or RPM should be applied to Update.1.

If there are any inter-dependencies on other fixes, this MUST be made clear clear.

The ticket should contain the patches being applied so that we can review them. If possible, please tell us how to verify the bug fix.

You MUST indicate who is going to verify the fix is in Ship.2, so it is obvious to whom the build engineer should reassign the bug.

Assign the trac bug to the user "ApprovalForUpdate". Add yourself to the list to ensure you get notification of any changes. This will let Jim/Kim/Walter have a single work queue; if you can catch us on IRC, you may be able to get approval immediately.

When the update is in the new Ship.2 build, the buildmeister will reassign it back to you.

You are then expected to test the resulting Ship.2 build, and mark the bug(s) closed and verified.