Page History
...
For code that requires modifications or additions to the existing suite of automated Lustre tests, the new or modified test scripts must be submitted with the patch. If there is a defect in the existing code, it means that there is no regression test that covers this code path. A new test should be written that confirms the problem be hit by the test before the fix is landed, and verifies the patch resolves the problem afterward. Any additional testing that cannot be covered by the existing automated Lustre tests must also be documented with a clear, step-by-step test plan, and arrangements must be made with the Lustre test team to execute these plans.
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.
| Code Block |
|---|
git clone ssh://review/fs/lustre-release
|
Push the change to the fs/lustre-release repository for inspection and eventual submission to the master branch:
| Code Block |
|---|
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:
...
Overview
Content Tools