Source Code Change Management

• Developers are encouraged to host changes in branches in personal git clones, against upstream master.
• Personal clones need to have an up-to-date copy of the upstream master branch for easy diffs in gitweb/cgit. This has the added benefit of working as a backup.
• When submitting a contribution send an URL to branch shortlog view with description, or for small things, a single .patch directly posted to a relevant freedesktop.org bug, creating one if necessary.
• All branches and patches need to be reviewed before merging to master.
• The "patch" keyword should be set for bugs where there is a branch/patch proposed for merging, and the assignee set to whoever posted the patch/branch URL. This starts the review process. Also when starting to work on an open issue, assign it to yourself, so ownership is clear.
• The reviewer approves patches by posting "review+" on the status whiteboard, along with a suitable comment.
• Updates or changes to a contribution (patch, branch) are requested with "review-" on whiteboard and explanatory comment.
• When the requested updates are done, the contributor comments with an explanation on that so renewed review can happen. The status whiteboard should be cleared when an updated patch is uploaded, or requested fixes to a branch have been made.
• A developer with commit access merges reviewed branches or patches to upstream master. Usually this is the developer of the changes, but for non-committer contributions a maintainer will take care to merge, preserving the authorship information.
• After merging, the issue in question needs to be set to RESOLVED Bugzilla state, and mention that the fix has been merged.