Canonical version of this page is at https://wiki.lustre.org/Commit_Comments

Commit message content

Writing good commit comments is critical to ensuring that changes are easily understood, even years after they were originally written. The commit comment should contain enough information about the change to allow the reader to understand the motivation for the change, what parts of the code it is affecting, and any interesting, unusual, or complex parts of the change to draw attention to.

...

The first line of the commit comment is the commit summary of the change. Changes submitted to the fs/lustre-release branch require a Lustre Jira ticket number at the beginning of the commit summary. A Lustre Jira ticket is one that begins with LU and is therefore part of the Lustre project within Jira.  For patches to other projects, such as documentation, a different JIRA project should be used (e.g. LUDOC). 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 would then need to fix the summary line and resubmit the patch.

The commit summary should also have a component: tag immediately following the Jira ticket number 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, osd-zfs, ldiskfs, lnet, libcfs, socklnd, o2iblnd; functional components like recovery, quota, grant; or auxiliary components like build, tests, iokit, docs. This subsystem list is not exhaustive, but provides a good guideline for consistency.

...

LU-nnn component: short description of change under 62 columns

The "component:" should be a lower-case single-word subsystem of the
Lustre code that best encompasses the change being made.  Examples of
components include modules: llite, lov, lmv, osc, mdc, ldlm, lnetmds, oss,
ptlrpc, mds, ossosd-ldiskfs, osd-ldiskfszfs, ldiskfs, libcfslnet, socklnd, o2iblnd, libcfs;
functional subsystems: recovery, quota, grant; and auxilliaryauxiliary areas:
build, tests, docs.  This list is not exhaustive, but is a guideline.

The commit comment should contain a detailed explanation of changes
being made.  This can be as long as you'd like.  Please give details
of what problem was solved (including error messages or problems that
were seen), a good high-level description of how it was solved, and
which parts of the code were changed (including important functions
that were changed, if this is useful to understand the patch, and
for easier searching).  Wrap lines at/under 70 columns.

Signed-off-by: Your Real Name <your_email@domain.name>
Change-Id: Ixxxx(added automatically if missing)xxxx

...

For patches backported from master to a Lustre maintenance branch (e.g. b2_510) there are some conventions to follow so that the changes/fixes can more easily be tracked across branches. The best simples method for porting a patch from one branch to another is to use to use the "Cherry Pick" button on the patch directly in Gerrit, which can be used for patches that apply cleanly to the specified target branch as long as it is in the same Git repository.  Alternately, if this is not possible, use git cherry-pick {commit_hash|branch} on the branch where from the command line to pull the patch onto the (current) branch where you want the patch to land, and then using the normal patch submission process to push the patch to Gerrit or submit it to the upstream kernel.  This will apply the whole patch (as best as is able, and show conflicts where needed), copy the commit message, preserve the original patch author.  With luck, there will not be any patch conflicts and no further work is needed.  If necessary, the patch conflicts need to be resolved before committing the patch.  For the commit message:

:

Patches ported from master to maintenance branch

For example, porting a patch from master to b2_10 or similar:

LU-4725 mdt: child-parent lock ordering in rename
    
Change rename so that it always has parent-child lock ordering,
otherwise it may deadlock with other operations.
    
Lustre-commit: 4e308ef74f271ec7e19917e3c0f88586537582c3
Lustre-change: http://review.whamcloud.com/9538
    
LU-4725 obd: lu_object_find_at hung
    
lu_object_find_at hangs if called two times and object is removed
in between. It makes mdt_rename_sanity not workable for rename.
Change mdt_rename_sanity to work on existing object.
    
Lustre-commit: b7c72ec1ddeda2cf94ea151f974d3f94e3a7d1ed
Lustre-change: http://review.whamcloud.com/10484
Xyratex-bug-id: MRP-1700
    
Test-Parameters: alwaysuploadlogs \
  envdefinitions=SLOW=yes,ENABLE_QUOTA=yes,ONLY=54 \
  ossjob=lustre-b2_4 mdsjob=lustre-b2_4 ossbuildno=73 mdsbuildno=73 \
  testlist=sanityn
    
Signed-off-by: Vitaly Fertman <vitaly_fertman@xyratex.com>
Signed-off-by: Rahul Deshmukh <rahul_deshmukh@xyratex.com>    
Change-Id: Ic9ce52bfcd8788834347fba155cc8c6be674dcd8

...

Patches ported from master to

...

upstream kernel

These are treated similarly as patches ported to maintenance branches (keep all comments and Signed-off-by: lines from the original patch) add new Signed-off-by: and comments afterward, but replace the Lustre-commit: line (which doesn't mean anything in the upstream kernel git) with Intel-bug-id: {jira_URL} so that the original bug can still be identified:Intel-bug-id: {jira_URL} so that the original bug can still be identified.  When submitting patches upstream, please also follow the Documentation/process/submitting-patches.rst instructions, and use scripts/get_maintainer.pl to generate the CC list for the patch.  If in doubt, submit the patch only to lustre-devel first to get feedback from the Lustre maintainers.

lustre/llite: simplify dentry revalidate
    
Lustre client dentry validation is protected by LDLM lock, so
any time a dentry is found, it's valid and no need to revalidate
from MDS, and even it does, there is race that it may be
invalidated after revalidation is finished.
    
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-on: http://review.whamcloud.com/7475
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3544
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>

...