Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

All patches that land on the main release branches in the fs/lustre-release repository must be tested, associated with a Lustre Jira ticket, and by signed off by the developer. In the future, some basic testing will be done automatically when the requested is created, but for now All changes submitted to the fs/lustre-release repository are also tested automatically with the Lustre regression tests in lustre/tests and a link to the test results (ideally saved in Maloo) can and a pass/fail review will be added to the Jira ticketGerrit change.

Signed-off-by

We are using the a similar sign-off process that is used for contributions to the Linux kernel. This means developers making contributions certify that they wrote the patch or have the right to pass it on. To certify this, you include a Signed-off-by: line like this one at the bottom of your commit comments:

...

The first line of the commit comment is the commit summary of the change. Changes submitted to the fs/lustre-release branch also require a Lustre Jira Lustre Jira issue tag at the beginning of the first line of the commit summary.   A Lustre Jira ticket is one that begins with LU and is therefore part of the Lustre project within Jira.  If If the patch is submitted for the fs/lustre-release repository without a Lustre Jira ID in the first line, then it will automatically receive a -2 review which will prevent the patch from being submitted to a release branch. You will get an e-mail about this rejection at which time you can add the line and resubmit the patch.   The commit summary should also have a component: field immediately following the Jira issue tag that indicates which Lustre subsystem that the commit is related to.   Example Lustre subsystems relate to modules like llite, lov, osc, mdc, lmv, ldlm, ptlrpc, mds, oss, mdd, osd, ldiskfs, lnet, libcfs, socklnd, o2iblnd; functional components like recovery, quota, grant; or auxiliary components like build, test, doc.   This subsystem list is not exhaustive, but should be used as a guideline for consistency.

The rest of the comments should be wrapped to 72 70 columns or less. This allows for the first line to be used a subject in emails, and also for the entire body to be displayed using tools like "git log" in an 80 column window.

Please make sure the Change-Id: line and Signed-off-by: lines are at the bottom of the comment. This is required by the fs/lustre-release project (at least) in order for the patch to be approved.  If If your comments are missing either of these lines the patch will be automatically be rejected at submission time.   See Using Gerrit for a description of the Change-Id: line .

Example comment
No Format
LU-999 component: short description of change under 64 columns

A more detailed explanation.  This can be as detailed as you'd like.
Please explain both what problem was solved and a good high-level
description of how it was solved.  Wrap lines at 72 columns or less.

Signed-off-by: Random J Developer <random@developer.example.org>
Change-Id: Ica9ed1612eab0c4673dee088f8b441d806c64932

...

Code Block
git clone ssh://review/fs/lustre-release

Push the change to the fs/lustre-release repo repository for inspection and eventual submittal to the master branch:

...

Once a change request has received at least two positive inspections (and ideally no negatives), the gatekeeper for the branch will, at her discretion, submit the change directly from gerritGerrit. If a patch no longer applies cleanly to the branch, then it will need to be updated by the developer, and the gatekeeper should be notified when the patch is ready again. The gatekeeper will decide if additional inspections are required or if it is ready to land.

...