Update.1 process

The following is a draft placeholder pending public discussion and comment.

Process to Propose Changes

1. You MUST notify the community of any significant code you expect will change in the next week as soon as possible.
2. To do this, you MUST create a ticket, tagged "Update.1?" in the keywords field. You MUST briefly justify your recommendation. You MUST include the date you expect your change will be available for testing in the "joyride" build. This date MUST be before November 2.
3. You SHOULD tag other people's bugs that you think should be included in Update.1. But remember that there is a finite amount of time and resources available as you make these recommendations, and state your reasoning why you think these fixes must be made by our first deployment release.
4. After November 1, the exact RPM or bundle version will be indicated in the ticket requesting the change in Update.1, with its checksum and diffs from the previous version, and proposed CHANGELOG entry. It must be is available in a Joyride build for testing and ready for inclusion in killjoy. We strongly encourage that you have someone other than yourself verify that your fix is correct and does not introduce regressions.

Process to Ratify Changes

The release team will approve tickets and assign to the (temporarily cscott until Dennis is up to speed) designated release engineer.

• there MUST be at least one ticket in Trac; 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, please make sure that is clear.

• the ticket should contain the patches being applied.

• Assign the trac bug to the user "ApprovalForUpdate". Add yourself to the list to ensure you get notification of any changes.

• If it is approved, we'll assign it to our buildmeister (cscott this instant, Dennis when he's ready) to process.

• When the update is in the new Update.1 build, the buildmeister will reassign it back to you.

• You are then expected to test the resulting update build, and mark the bug closed and verified.