WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.
Submitting Patches: Difference between revisions
| Line 41: | Line 41: | ||
17 Prepare for landing | 17 Prepare for landing [[https://wikis.clusterfs.com/intra/index.php/Developer_Process#Prepare_for_landing]] | ||
Possibly relevant but might need tailoring for external audience as we want community contributors to submit fixes for us to review and land, not to land themselves | Possibly relevant but might need tailoring for external audience as we want community contributors to submit fixes for us to review and land, not to land themselves | ||
* and | * and | ||
14 Testing and Landing | 14 Testing and Landing [[https://wikis.clusterfs.com/intra/index.php/Developer_Process#Testing_and_Landing]] | ||
Revision as of 16:14, 29 August 2009
When you are ready to have your patch reviewed and committed, please do so using Bugzilla by following the process described below.
Submitting Patches for Review
To have your changes accepted into a main-line Lustre branch, your code must be reviewed and approved. Following these steps will speed up review of your changes and increase the likelihood of success:
1. Read, complete, and return the form found at Contributor Agreement We cannot accept your contributions without this form. See Contribution Policy for more information.
2. Generate a patch with the "-upN" flags set to diff or cvs diff. Please do not send other kinds of patches unless your reviewer requests them.
Would this step be clearer if it said something like this?
$ cvs diff -upN FILENAME (please fix if not correct)
Where N designates the number of lines of context to include. Please do not send other kinds of patches unless your reviewer requests them.
3. Find or file a bug corresponding to your contribution at http://bugzilla.lustre.org/ . For more information about Bugzilla, see the Bugzilla - Bug Writing Guidelines or the Bugzilla User Guide.
- Provide the patch as an Attachment (click on "Add an Attachment")
- Select the "patch" box.
- Edit the new attachment. Under "Flags" select "Review" - is this correct?-I don't see this entry in Bugzilla and set the flag to a question mark (?).
- Enter the email address of the person who should review. If you have not been collaborating with someone and don't know who should review your work, send an email to lustre-rmg-team@sun.com
- Click on "commit" to submit the attachment update.
4. One or more reviewers will submit comments regarding your patch. Iterate the patch until you receive approval or the bug is closed.
5. Once you have approval, commit the patch (or, if you do not have CVS access, ask for it to be committed for you). Include the bug number and reviewer in the commit message, along with a concise description of the change.
Note: This process applies even if you have write access to the CVS tree. If you do not follow these steps, then expect your changes to be backed out of the tree without warning.
Creating a Private Branch in CVS
Our current policy is that anyone may create and maintain a private branch in CVS. We ask, however, that you observe the best practices outlined in this document can a link be provided?. It will save you a lot of effort.
If you have demonstrated a history of good work by submitting several non-trivial and correct patches, you may want to request write access to the CVS tree.
Include any from here?
17 Prepare for landing [[1]] Possibly relevant but might need tailoring for external audience as we want community contributors to submit fixes for us to review and land, not to land themselves
- and
14 Testing and Landing [[2]]
