Gerrit Workflow

We're using Gerrit for code inspections and for managing changes to branches. The workflow for a change in Gerrit begins with an inspection request, and once the request has been approved, it is pushed directly to the branch by the gatekeeper. We don't need to manage patches externally, or manage our landing process using other tools - all of it can be done in Gerrit. Please review the Using Gerrit page for more details on how gerrit and git are used together.

Requirements for patch submission

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 a link to the test results (ideally saved in Maloo) can be added to the Jira ticket.

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:

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

Adding this line means that you certify the following:

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Changes submitted to to the release branch without the Signed-off-by line will be rejected.

Jira issue tag

Changes submitted to the fs/lustre-release branch also require a Lustre Jira issue tag at the beginning of the first line of the change comment. A Lustre Jira ticket is one that begins with LU and is therefore part of the Lustre project within Jira. Changes submitted without this LU-xxx tag will not be rejected on submission but will be reviewed negatively enough to prevent the patch from landing.  You will get an e-mail about this rejection at which time you can add the line and resubmit the patch.

Example comment
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

Submitting a change to a Lustre Release

The git URLs here assume you have updated your ~/.ssh/config using the suggestions in Using Gerrit.

The repository we are using for releases is fs/lustre-release. This is the repository to push to when you request an inspection for a change that is ready for a release. There are currently only two branches here, b1_8 and master, which is the branch for 2.X releases.

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

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

git push origin HEAD:refs/for/master

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 gerrit. 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.

Patch landing process

Brief summary for landing patch to lustre in Whamcloud:

  1. Test and commit your patch locally.
  2. Push your patch to Gerrit for inspection, and specify two inspectors.
  3. Test your patch on real cluster and upload your test results to Maloo.
  4. Add a comment on Gerrit with the Maloo link to indicate that the patch works.
  5. Add the branch gatekeeper as inspector on Gerrit to notify him/her that the patch is ready.
  6. The branch gatekeeper will review the patch, confirm the test results, and submit it when everything goes well.
  7. If the submission failed due to conflict(s), the gatekeeper will ask you to rebase your patch with the target branch and repeat above steps.
  8. If your patch is useful for other branch(es), please repeat above steps against corresponding branch(es).