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
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
When you are ready to have your patch reviewed, follow the process described below for submitting it using Bugzilla. | When you are ready to have your patch reviewed, follow the process described below for submitting it using Bugzilla. | ||
'''''Note:''''' It is sometimes desirable to solicit reviews of a patch on the [mailto:lustre-devel@lists.lustre.org lustre-devel] mailing list to expose the patch to a wider audience. However, this will | '''''Note:''''' It is sometimes desirable to solicit reviews of a patch on the [mailto:lustre-devel@lists.lustre.org lustre-devel] mailing list to expose the patch to a wider audience. However, this will ''NOT'' put the patch on track to being accepted into the Lustre repository. | ||
=== Submitting Patches for Review === | === Submitting Patches for Review === | ||
| Line 7: | Line 7: | ||
To have your changes accepted into a mainline Lustre branch, your code must be reviewed and approved by senior Lustre engineers. Following these steps will speed up review of your changes and increase the likelihood of success: | To have your changes accepted into a mainline Lustre branch, your code must be reviewed and approved by senior Lustre engineers. 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 [http://wiki.lustre.org/images/c/cd/Sun_Contributor_Agreement_1_5.pdf Contributor Agreement] | 1. Read, complete, and return the form found at [http://wiki.lustre.org/images/c/cd/Sun_Contributor_Agreement_1_5.pdf Contributor Agreement]. We cannot accept your contributions without this form. See [[Contribution_Policy|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. It is possible to have these flags set as default by moving/adding the ''build/cvsrc'' and/or ''build/quiltrc'' to the respective ''.cvsrc'' and ''.quiltrc'' files in your home directory. | 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. It is possible to have these flags set as default by moving/adding the ''build/cvsrc'' and/or ''build/quiltrc'' to the respective ''.cvsrc'' and ''.quiltrc'' files in your home directory. | ||
| Line 20: | Line 20: | ||
</pre> | </pre> | ||
Using the ''-N'' flag for the entire | Using the ''-N'' flag for the entire CVS diff will potentially include a number of unrelated files and should be avoided. After the patch has been created, it should be opened in an editor to verify that it contains all and only the changes you are expecting. | ||
3. Find or file a bug corresponding to your contribution at http://bugzilla.lustre.org/. For more information about Bugzilla, see the [https://bugzilla.lustre.org/page.cgi?id=bug-writing.html Bugzilla - Bug Writing Guidelines] or the [https://bugzilla.lustre.org/docs/html/using.html Bugzilla User Guide]. | 3. Find or file a bug corresponding to your contribution at http://bugzilla.lustre.org/. For more information about Bugzilla, see the [https://bugzilla.lustre.org/page.cgi?id=bug-writing.html Bugzilla - Bug Writing Guidelines] or the [https://bugzilla.lustre.org/docs/html/using.html Bugzilla User Guide]. | ||
| Line 27: | Line 27: | ||
* Select the "patch" box. | * Select the "patch" box. | ||
** If submitting a new bug with a patch attached, follow normal bug submission procedures. The support team will assign the bug and inspections as appropriate. | ** If submitting a new bug with a patch attached, follow normal bug submission procedures. The support team will assign the bug and inspections as appropriate. | ||
** If working with an Lustre internal engineer, under "Flags" set the | ** If working with an Lustre internal engineer, under "Flags" set the ''inspection'' flag to "?" and copy the email address of the engineer into the adjacent ''Requestee:'' field. | ||
** If you have not been collaborating with someone on the Lustre team and don't know who should review your work, assign the inspection to | ** If you have not been collaborating with someone on the Lustre team and don't know who should review your work, assign the inspection to ''lustre-rmg-team@sun.com'' | ||
* Click on "commit" to submit the attachment and inspection request. | * Click on "commit" to submit the attachment and inspection request. | ||
4. | 4. Testing the patch is required before it can be committed to CVS. See [[Testing Lustre Code]] for specific details. If you have completed testing of the patch, including the addition of tests specific to any defect that is found and/or new functionality that has been added. Set the "acc-sm_passed_''release''" flag to "+" for the branch(es) that passed testing. | ||
5. | 5. One or more reviewers will submit comments regarding your patch. Iterate the patch until you receive inspection approval or the bug is closed. | ||
6. Once you have approval, commit the patch (or, if you do not have CVS write access, the internal | 6. Once you have approval, commit the patch (or, if you do not have CVS write access, the internal | ||
Revision as of 10:42, 7 September 2009
When you are ready to have your patch reviewed, follow the process described below for submitting it using Bugzilla.
Note: It is sometimes desirable to solicit reviews of a patch on the lustre-devel mailing list to expose the patch to a wider audience. However, this will NOT put the patch on track to being accepted into the Lustre repository.
Submitting Patches for Review
To have your changes accepted into a mainline Lustre branch, your code must be reviewed and approved by senior Lustre engineers. 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. It is possible to have these flags set as default by moving/adding the build/cvsrc and/or build/quiltrc to the respective .cvsrc and .quiltrc files in your home directory.
The command for generating a patch is:
[lustre]$ cvs diff -up > {patchname}.diff
If you have added a new file, include the new file in the patch:
[lustre]$ cvs diff -upN {path_to_new_file} >> {patchname}.diff
Using the -N flag for the entire CVS diff will potentially include a number of unrelated files and should be avoided. After the patch has been created, it should be opened in an editor to verify that it contains all and only the changes you are expecting.
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.
- If submitting a new bug with a patch attached, follow normal bug submission procedures. The support team will assign the bug and inspections as appropriate.
- If working with an Lustre internal engineer, under "Flags" set the inspection flag to "?" and copy the email address of the engineer into the adjacent Requestee: field.
- If you have not been collaborating with someone on the Lustre team and don't know who should review your work, assign the inspection to lustre-rmg-team@sun.com
- Click on "commit" to submit the attachment and inspection request.
4. Testing the patch is required before it can be committed to CVS. See Testing Lustre Code for specific details. If you have completed testing of the patch, including the addition of tests specific to any defect that is found and/or new functionality that has been added. Set the "acc-sm_passed_release" flag to "+" for the branch(es) that passed testing.
5. One or more reviewers will submit comments regarding your patch. Iterate the patch until you receive inspection approval or the bug is closed.
6. Once you have approval, commit the patch (or, if you do not have CVS write access, the internal engineer assigned to the bug will direct the bug appropriately or land the change). Include the bug number and reviewer in the commit message, along with a concise description of the change. See build/cvsdiffclient and build/cvs-modified-files.pl in the lustre source tree for commit template generation.
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.
