Submitting Changes - Revision history

Adilger: fix link to mailing list page

2026-07-23T22:49:27Z

fix link to mailing list page

← Older revision		Revision as of 15:49, 23 July 2026
Line 74:		Line 74:
	==Seeking Guidance==		==Seeking Guidance==

	Please alert other Lustre developers via the [[~~Mailing_Lists_and_IRC~~\|lustre-devel]] mailing list if you need some extra guidance in getting your patch submitted for the release.		Please alert other Lustre developers via the [[Mailing_Lists_and_Messaging\|lustre-devel]] mailing list if you need some extra guidance in getting your patch submitted for the release.

	[[Category:Development]]		[[Category:Development]]

Adilger: /* First Steps */ fix link to mailing list page

2026-07-23T22:28:48Z

First Steps: fix link to mailing list page

← Older revision		Revision as of 15:28, 23 July 2026
Line 43:		Line 43:
	You should check the [[Projects]] page to see if anyone is already working on something similar. If someone is then add yourself as a watcher to the JIRA ticket and offer to collaborate.		You should check the [[Projects]] page to see if anyone is already working on something similar. If someone is then add yourself as a watcher to the JIRA ticket and offer to collaborate.

	If you are unable to find a match, then open a new [https://jira.whamcloud.com/ JIRA] ticket outlining your plans (more detail is better than less), including the intended purpose of the development and any initial thoughts on design. An entry should be added to the [[Projects]] page under [[Projects#Future_Projects]] with a brief summary of your feature/project. Then, mail the [[~~Mailing_Lists_and_IRC~~\|lustre-devel]] mailing list to draw attention to the ticket. This will alert the community members of your intentions and may well result in potential collaborators stepping forward.		If you are unable to find a match, then open a new [https://jira.whamcloud.com/ JIRA] ticket outlining your plans (more detail is better than less), including the intended purpose of the development and any initial thoughts on design. An entry should be added to the [[Projects]] page under [[Projects#Future_Projects]] with a brief summary of your feature/project. Then, mail the [[Mailing_Lists_and_Messaging\|lustre-devel]] mailing list to draw attention to the ticket. This will alert the community members of your intentions and may well result in potential collaborators stepping forward.

	If you choose not to do this you may find that you are either duplicating work with someone else, or that your code needs to be reworked to accommodate other changes occurring in the same part of Lustre code.		If you choose not to do this you may find that you are either duplicating work with someone else, or that your code needs to be reworked to accommodate other changes occurring in the same part of Lustre code.
Line 49:		Line 49:
	While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.		While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.

	It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Look at the [https://jira.whamcloud.com/issues/?jql=labels%20%3D%20easy%20AND%20resolution%20%3D%20unresolved easy projects] list, and/or feel free to ask for suggestions on the [[~~Mailing_Lists_and_IRC~~\|lustre-devel]] mailing list for a suitable bug to get started with.		It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Look at the [https://jira.whamcloud.com/issues/?jql=labels%20%3D%20easy%20AND%20resolution%20%3D%20unresolved easy projects] list, and/or feel free to ask for suggestions on the [[Mailing_Lists_and_Messaging\|lustre-devel]] mailing list for a suitable bug to get started with.

	===Schedule and Timing===		===Schedule and Timing===

Adilger: /* Patch Landing Checklist */ remove dead link

2020-01-30T21:52:26Z

Patch Landing Checklist: remove dead link

← Older revision		Revision as of 14:52, 30 January 2020
Line 10:		Line 10:
	# A [https://jira.whamcloud.com/ JIRA ticket] has been opened to track the issue		# A [https://jira.whamcloud.com/ JIRA ticket] has been opened to track the issue
	# Test your change locally using [[TestingLustreCode\|acceptance-small.sh]]		# Test your change locally using [[TestingLustreCode\|acceptance-small.sh]]
	# Commit the change after verifying it follows the ~~[[Requirements~~ for patch submission]]:		# Commit the change after verifying it follows the requirements for patch submission:
	## The [[Commit Comments]] are well formatted and useful		## The [[Commit Comments]] are well formatted and useful
	## Verify patch follows [[Lustre Coding Style Guidelines]] (at least '''git show \| contrib/scripts/checkpatch.pl -''' passes)		## Verify patch follows [[Lustre Coding Style Guidelines]] (at least '''git show \| contrib/scripts/checkpatch.pl -''' passes)

Adilger: /* Landing a Patch to a Lustre Release */ update description

2020-01-30T21:51:58Z

Landing a Patch to a Lustre Release: update description

← Older revision		Revision as of 14:51, 30 January 2020
Line 9:		Line 9:
	=== Patch Landing Checklist ===		=== Patch Landing Checklist ===
	# A [https://jira.whamcloud.com/ JIRA ticket] has been opened to track the issue		# A [https://jira.whamcloud.com/ JIRA ticket] has been opened to track the issue
	# Test ~~and commit~~ your ~~patch~~ locally using [[TestingLustreCode\|acceptance-small.sh]]		# Test your change locally using [[TestingLustreCode\|acceptance-small.sh]]
	# ~~The patch~~ follows the [[Requirements for patch submission]]:		# Commit the change after verifying it follows the [[Requirements for patch submission]]:
	## The [[Commit Comments]] are well formatted and useful		## The [[Commit Comments]] are well formatted and useful
	## Verify patch follows [[Lustre Coding Style Guidelines]] (at least '''git show \| contrib/scripts/checkpatch.pl -''' passes)		## Verify patch follows [[Lustre Coding Style Guidelines]] (at least '''git show \| contrib/scripts/checkpatch.pl -''' passes)
	## A [[TestingLustreCode\|regression test]] has been created that fails without the patch and passes with the patch		## A [[TestingLustreCode\|regression test]] has been created that fails without the patch and passes with the patch
	## The patch has the appropriate Signed off by line		## The patch has the appropriate '''Signed-off-by:''' line
	# ~~The~~ patch ~~has been uploaded~~ to [[Using Gerrit\|Gerrit]]		# Upload the patch to [[Using Gerrit\|Gerrit]] and review the test results
	# Request at least two [[Patch Inspection]] approvals on the Gerrit change (preferably ones with experience in this area of code as indicated on the [[Code Reviewers]] page)		## Check that the newly-added test(s) for the change are passing (new or modified tests will be run repeatedly to ensure they are passing consistently)
			## Review any other test failures (there may be some intermittent failures hit)
			## Associate known failures with existing LU tickets (by searching Jira and/or [https://testing.whamcloud.com/sub_tests/query Maloo] for similar subtest failures
			## Raise bug(s) for failures that are '''also seen on other patches'' that do not have an existing LU ticket
			## Fix failures that are associated with '''only your ticket''' ''even if you think they are unrelated'', as patches that cause failures cannot be landed
			## Retest any sessions that failed with known issues, or resubmit your patch if it needs changes
			# Request at least two [[Patch Inspection]] approvals on the Gerrit change (preferably ones with experience in this area of code as indicated by '''contrib/scripts/get_maintainer.pl'', or on the [[Code Reviewers]] page)
	# Record the Gerrit change URL in the Jira ticket (this is normally done automatically by Gerrit)		# Record the Gerrit change URL in the Jira ticket (this is normally done automatically by Gerrit)
	# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.		# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.
	# Once [https://testing.whamcloud.com Maloo] has reported the tests all pass and the patch has two positive reviews (other than the Author), the Gatekeeper will be notified that the patch is ready to be merged		# Once [https://testing.whamcloud.com/ Maloo] has reported the tests all pass and the patch has two positive reviews (other than the Author), the Gatekeeper will automatically be notified that the patch is ready to be merged
	# The Gatekeeper will review the patch, confirm the test results and inspections, and submit it after local merge testing		# The Gatekeeper will review the patch, confirm the test results and inspections, run additional merge testing, and submit it after local merge testing. This will take about a week after the patch is first ready to land.
	# If the submission failed due to patch conflict(s), the Gatekeeper will ask you to rebase your patch with the target branch and repeat above steps.		# If the submission failed due to patch conflict(s) or regressions, the Gatekeeper will ask you to rebase your patch with the target branch and repeat the above steps.
	# If your patch is needed for other branch(es), please repeat above steps against corresponding branch(es) (the same Jira ticket and Gerrit '''Change-Id''' should ~~be used).~~ If the patch has no conflicts, it can be '''Cherry-picked''' to the other branches directly from Gerrit.		# If your patch is needed for other branch(es), please repeat above steps against corresponding branch(es):
			## Use the same Jira ticket and Gerrit '''Change-Id''' labels
			## Add '''Lustre-commit:''' and '''Lustre-change:''' labels should
			## Remove the '''Reviewed-on:''' and '''Tested-by:''' labels from the previous commit message
			## If the patch has no conflicts, it can be '''Cherry-picked''' to the other branches directly from Gerrit after editing the commit message as described.

	==Landing a Feature to a Feature Release==		==Landing a Feature to a Feature Release==

Adilger: fix links

2018-06-22T17:40:03Z

fix links

Adilger: /* Seeking Guidance */ add links

2018-06-04T22:33:20Z

Seeking Guidance: add links

← Older revision		Revision as of 15:33, 4 June 2018
Line 65:		Line 65:
	==Seeking Guidance==		==Seeking Guidance==

	Please alert other Lustre developers via the lustre-devel mailing list if you need some extra guidance in getting your patch submitted for the release.		Please alert other Lustre developers via the [[Mailing_Lists_and_IRC\|lustre-devel]] mailing list if you need some extra guidance in getting your patch submitted for the release.

			[[Category:Development]]

Adilger: /* Landing a Patch to a Lustre Release */ link to Using Gerrit page

2018-06-04T06:31:17Z

Landing a Patch to a Lustre Release: link to Using Gerrit page

← Older revision		Revision as of 23:31, 3 June 2018
Line 16:		Line 16:
	## A [[TestingLustreCode\|regression test]] has been created that fails without the patch and passes with the patch		## A [[TestingLustreCode\|regression test]] has been created that fails without the patch and passes with the patch
	## The patch has the appropriate Signed off by line		## The patch has the appropriate Signed off by line
	# The patch has been uploaded to [~~https://review.whamcloud.com/~~ Gerrit]		# The patch has been uploaded to [[Using Gerrit\|Gerrit]]
	# Request at least two [[Patch Inspection]] approvals on the Gerrit change (preferably ones with experience in this area of code as indicated on the [[Code Reviewers]] page)		# Request at least two [[Patch Inspection]] approvals on the Gerrit change (preferably ones with experience in this area of code as indicated on the [[Code Reviewers]] page)
	# Record the Gerrit change URL in the Jira ticket		# Record the Gerrit change URL in the Jira ticket (this is normally done automatically by Gerrit)
	# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.		# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.
	# Once [https://testing.hpdd.intel.com Maloo] has reported the tests all pass, ~~add Gerrit~~ Gatekeeper ~~as inspector on the patch to notify him/her~~ that the patch is ready to be merged		# Once [https://testing.hpdd.intel.com Maloo] has reported the tests all pass and the patch has two positive reviews (other than the Author), the Gatekeeper will be notified that the patch is ready to be merged
	# The ~~branch gatekeeper~~ will review the patch, confirm the test results and inspections, and submit it ~~when everything goes well~~		# The Gatekeeper will review the patch, confirm the test results and inspections, and submit it after local merge testing
	# If the submission failed due to patch conflict(s), the ~~gatekeeper~~ will ask you to rebase your patch with the target branch and repeat above steps.		# If the submission failed due to patch conflict(s), the Gatekeeper will ask you to rebase your patch with the target branch and repeat above steps.
	# If your patch is needed for other branch(es), please repeat above steps against corresponding branch(es) (the same Jira ticket should be used).		# If your patch is needed for other branch(es), please repeat above steps against corresponding branch(es) (the same Jira ticket and Gerrit '''Change-Id''' should be used). If the patch has no conflicts, it can be '''Cherry-picked''' to the other branches directly from Gerrit.

	==Landing a Feature to a Feature Release==		==Landing a Feature to a Feature Release==

Adilger: /* Patch Landing Checklist */ link to renamed page

2016-02-16T19:13:34Z

Patch Landing Checklist: link to renamed page

← Older revision		Revision as of 12:13, 16 February 2016
Line 13:		Line 13:
	# The patch follows the [[Requirements for patch submission]]:		# The patch follows the [[Requirements for patch submission]]:
	## The [[Commit Comments]] are well formatted and useful		## The [[Commit Comments]] are well formatted and useful
	## Verify patch follows [[Lustre Coding Guidelines]] (at least '''git show \| contrib/scripts/checkpatch.pl -''' passes)		## Verify patch follows [[Lustre Coding Style Guidelines]] (at least '''git show \| contrib/scripts/checkpatch.pl -''' passes)
	## A [[TestingLustreCode\|regression test]] has been created that fails without the patch and passes with the patch		## A [[TestingLustreCode\|regression test]] has been created that fails without the patch and passes with the patch
	## The patch has the appropriate Signed off by line		## The patch has the appropriate Signed off by line

Spitzcor at 16:19, 1 December 2015

2015-12-01T16:19:43Z

← Older revision		Revision as of 09:19, 1 December 2015
Line 17:		Line 17:
	## The patch has the appropriate Signed off by line		## The patch has the appropriate Signed off by line
	# The patch has been uploaded to [https://review.whamcloud.com/ Gerrit]		# The patch has been uploaded to [https://review.whamcloud.com/ Gerrit]
	# Request at least two [[Patch Inspection]] approvals (preferably ones with experience in this area of code) on the ~~Gerrit change~~		# Request at least two [[Patch Inspection]] approvals on the Gerrit change (preferably ones with experience in this area of code as indicated on the [[Code Reviewers]] page)
	# Record the Gerrit change URL in the Jira ticket		# Record the Gerrit change URL in the Jira ticket
	# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.		# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.

Adilger: /* First Steps */ change "easy projects" list to only show open items

2015-08-20T22:03:56Z

First Steps: change "easy projects" list to only show open items

← Older revision		Revision as of 15:03, 20 August 2015
Line 40:		Line 40:
	While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.		While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.

	It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Look at the [https://jira.hpdd.intel.com/issues/?jql=labels%20%3D%20easy easy projects] list, and/or feel free to ask for suggestions on the [[Mailing_Lists_and_IRC\|lustre-devel]] mailing list for a suitable bug to get started with.		It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Look at the [https://jira.hpdd.intel.com/issues/?jql=labels%20%3D%20easy%20AND%20resolution%20%3D%20unresolved easy projects] list, and/or feel free to ask for suggestions on the [[Mailing_Lists_and_IRC\|lustre-devel]] mailing list for a suitable bug to get started with.

	===Schedule and Timing===		===Schedule and Timing===

← Older revision		Revision as of 10:40, 22 June 2018
Line 1:		Line 1:
	~~<small>''(Copied from [https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes Intel HPDD wiki Submitting Changes] August 2015)''</small>~~
	== Lustre Quality ==		== Lustre Quality ==
	A lot of work has been put into stabilizing Lustre over the years, and we have evolved processes to ensure we maintain the stability that so many sites worldwide now rely on for their site-wide production filesystems. In many sites, when Lustre stops working many millions of dollars of computing equipment sits idle, so stability of Lustre is the top criterion for all development.		A lot of work has been put into stabilizing Lustre over the years, and we have evolved processes to ensure we maintain the stability that so many sites worldwide now rely on for their site-wide production filesystems. In many sites, when Lustre stops working many millions of dollars of computing equipment sits idle, so stability of Lustre is the top criterion for all development.
Line 9:		Line 8:

	=== Patch Landing Checklist ===		=== Patch Landing Checklist ===
	# A [https://jira.~~hpdd.intel~~.com/ JIRA ticket] has been opened to track the issue		# A [https://jira.whamcloud.com/ JIRA ticket] has been opened to track the issue
	# Test and commit your patch locally using [[TestingLustreCode\|acceptance-small.sh]]		# Test and commit your patch locally using [[TestingLustreCode\|acceptance-small.sh]]
	# The patch follows the [[Requirements for patch submission]]:		# The patch follows the [[Requirements for patch submission]]:
Line 20:		Line 19:
	# Record the Gerrit change URL in the Jira ticket (this is normally done automatically by Gerrit)		# Record the Gerrit change URL in the Jira ticket (this is normally done automatically by Gerrit)
	# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.		# Additional test results appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.
	# Once [https://testing.~~hpdd.intel~~.com Maloo] has reported the tests all pass and the patch has two positive reviews (other than the Author), the Gatekeeper will be notified that the patch is ready to be merged		# Once [https://testing.whamcloud.com Maloo] has reported the tests all pass and the patch has two positive reviews (other than the Author), the Gatekeeper will be notified that the patch is ready to be merged
	# The Gatekeeper will review the patch, confirm the test results and inspections, and submit it after local merge testing		# The Gatekeeper will review the patch, confirm the test results and inspections, and submit it after local merge testing
	# If the submission failed due to patch conflict(s), the Gatekeeper will ask you to rebase your patch with the target branch and repeat above steps.		# If the submission failed due to patch conflict(s), the Gatekeeper will ask you to rebase your patch with the target branch and repeat above steps.
Line 34:		Line 33:
	You should check the [[Projects]] page to see if anyone is already working on something similar. If someone is then add yourself as a watcher to the JIRA ticket and offer to collaborate.		You should check the [[Projects]] page to see if anyone is already working on something similar. If someone is then add yourself as a watcher to the JIRA ticket and offer to collaborate.

	If you are unable to find a match, then open a new [https://jira.~~hpdd.intel~~.com/ JIRA] ticket outlining your plans (more detail is better than less), including the intended purpose of the development and any initial thoughts on design. An entry should be added to the [[Projects]] page under [[Projects#Future_Projects]] with a brief summary of your feature/project. Then, mail the [[Mailing_Lists_and_IRC\|lustre-devel]] mailing list to draw attention to the ticket. This will alert the community members of your intentions and may well result in potential collaborators stepping forward.		If you are unable to find a match, then open a new [https://jira.whamcloud.com/ JIRA] ticket outlining your plans (more detail is better than less), including the intended purpose of the development and any initial thoughts on design. An entry should be added to the [[Projects]] page under [[Projects#Future_Projects]] with a brief summary of your feature/project. Then, mail the [[Mailing_Lists_and_IRC\|lustre-devel]] mailing list to draw attention to the ticket. This will alert the community members of your intentions and may well result in potential collaborators stepping forward.

	If you choose not to do this you may find that you are either duplicating work with someone else, or that your code needs to be reworked to accommodate other changes occurring in the same part of Lustre code.		If you choose not to do this you may find that you are either duplicating work with someone else, or that your code needs to be reworked to accommodate other changes occurring in the same part of Lustre code.
Line 40:		Line 39:
	While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.		While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.

	It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Look at the [https://jira.~~hpdd.intel~~.com/issues/?jql=labels%20%3D%20easy%20AND%20resolution%20%3D%20unresolved easy projects] list, and/or feel free to ask for suggestions on the [[Mailing_Lists_and_IRC\|lustre-devel]] mailing list for a suitable bug to get started with.		It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Look at the [https://jira.whamcloud.com/issues/?jql=labels%20%3D%20easy%20AND%20resolution%20%3D%20unresolved easy projects] list, and/or feel free to ask for suggestions on the [[Mailing_Lists_and_IRC\|lustre-devel]] mailing list for a suitable bug to get started with.

	===Schedule and Timing===		===Schedule and Timing===
Line 53:		Line 52:
	* T-3 Feature Freeze - feature landing is finished, bug fixes only from now on. The appropriate release page is updated.		* T-3 Feature Freeze - feature landing is finished, bug fixes only from now on. The appropriate release page is updated.
	* T-1 Code Freeze - critical bug fixes only from now on. A release candidate (RC) is tagged and release testing commences		* T-1 Code Freeze - critical bug fixes only from now on. A release candidate (RC) is tagged and release testing commences
	* T0 GA announced and RPMs available for download from the [http://downloads.~~hpdd.intel~~.com/public/lustre/ download] site		* T0 GA announced and RPMs available for download from the [http://downloads.whamcloud.com/public/lustre/ download] site

	==Feature Landing Checklist==		==Feature Landing Checklist==