3:16 p.m.
I'd like to get some consistency with the commit messages when porting
patches between branches, and when porting patches to the upstream kernel.
There are a number of standard tags that are already used, such as
Signed-off-by: and Change-Id: that should continue to be used, but there
needs to be some consistent way to track if a patch landed on b2_1 is
based on a patch landed originally on another branch, possibly originally
under a different bug number and with a different commit summary.
Firstly, when porting a patch it is important to use "git cherry-pick
{hash}" or "git am {patch}" to preserve the original author, commit
comments, and patch summary line. It is fine to _expand_ the commit
comments if they were originally not clear enough, but rarely does it make
sense to reduce the comments. Patch descriptions like "backport LU-1234
fix to b2_1" are not very useful, since they impose a burden on the reader
to dig into Jira and Gerrit to find what the patch actually does.
If the patch was originally from a different Jira bug that was
rediscovered on a different branch, or if it is landing upstream then it
makes sense to link the old patch to the new bug for tracking. There has
already been the XXXXX-bug-id: tag in use for identifying patches from
Xyratex Jira, or originally from an Oracle bugzilla, so it is possible to
use:
Intel-bug-id: LU-NNNN
to identify the duplicate issue. The original Jira ticket should stay in
the patch summary, so that "git shortlog" can be used for comparison.
The current version of Gerrit does not play well with re-using the same
Change-Id: line for multiple branches, so a new Change-Id: line is needed.
We are planning to upgrade Gerrit after 2.4.0 is released, and maybe it
will be possible to keep the same Change-Id: in the future.
I'd like to keep links to the original Git commit hash and change like:
Lustre-commit: f62391735dce440addba54c9a7640e2fdff5ea23
Lustre-change: http://review.whamcloud.com/6383
The full commit hash is important for upstream kernel submission, since a
short commit hash like f62391 has a good chance of collisions with the
upstream kernel (the kernel has about 200k patches, which is about 1/8 of
all the 6-character hashes already).
Finally, it makes sense to preserve the original reviewers of the patch.
This automatically adds them as reviewers for the new patch in Gerrit as
well:
Reviewed-by: Andreas Dilger <andreas.dilger(a)intel.com>
Reviewed-by: Mike Pershin <mike.pershin(a)intel.com>
I'll add all of this information to the wiki as well, but wanted to get it
to a wider audience also.
Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel High Performance Data Division