Contents |
We are trying to keep Flock's code bug free, homogeneous and maintainable. For that reason, even a patch that is working can be rejected if a module owner, release driver, or branch maintainer thinks that the bug should be fixed in a different way. If you want to increase your chances to have your patch integrated into the Flock codebase, please be careful to:
All patches, in order to be accepted into the Flock codebase, must be attached against a Bugzilla bug report. If you can't find an existing bug report relevant to your fix, then you must file a bug report first. The bug description should clearly define what the problem (or enhancement request) is, and the attachment description must clearly and succinctly describe what the approach of the fix was that your patch contains. It should also indicate the branch(es) and code version(s) that you tested your patch with.
When uploading your patch (or after uploading if you click [Edit] on the patch) you can change a number of metadata flags and fields related to your patch. You must set the "review" flag to "?". This indicates that you are requesting your patch be reviewed. If you happen to know somebody who would be ideally suited to review your patch, enter their email address.
The functional area owner (or the named reviewer) updates the bug with the status of the review and a date to expect further updates. From then on the reviewer always includes a date to expect further updates. The area owner (or the QA contact) can delegate the patch review to an other developer.
If the patch passes muster, you will receive a "review+" or "r+" or "r=<reviewer_name>". This means you may proceed to the next step of requesting approval. (See below.)
If the patch requires changes, you will get "review-" or "r-". The reviewer must describe why the patch failed review, and suggest improvements to make. Make the recommended changes and roll a new patch incorporating those suggestions. The new patch should be a *replacement* for the old one, not an amendment to it. When you upload your new patch to the bug, check the "Obsoletes" checkbox next to the name of the old patch you are replacing. Then request review again.
Once you have a patch that has passed review, you need to request approval to "land" it on the main development trunk, or on particular branches. The flags for doing this are on the Edit Patch page. You could, for example, set the "approvalEagle" flag to "?", meaning that you are requesting approval to land the patch on the "eagle" branch. Approval must be granted by a branch maintainer or release driver before you may commit the patch.
Make sure that you understand the branching plan, so that you know which branches (and/or trunk) the patch needs to be applied to so that the bug will not re-surface in a future release! In some cases one patch can be rolled that will apply against multiple branches; but in other cases, separate patches will have to be prepared for the separate branches.
Once you receive approval+ (or approvalEagle+, etc...) you may commit your patch to SVN. Your commit message should follow this basic format:
[<bug#>] <succinct description of patch contents> r=<reviewer_name> a=<approver_name>
Make sure to wrap your lines somewhere around 72-74 characters. Make sure, also, that your description provides adequate detail. "Fixed the bug" is not an acceptable level of detail, nor is "made the changes recommended by the reviewer".
Once the patch has been reviewed, approved, and committed to all necessary branches (and/or trunk), you may mark the bug as FIXED.
We should identify what type of patches always have to be reviewed by the "theme" owner because the theme is the most fragile.