How to submit a patch to OpenEmbedded - Revision history

JPEWhacker: Moved to YP docs

2023-08-30T15:31:36Z

Moved to YP docs

Michael Opdenacker: Mark this page as obsolete and redirect to new location.

2023-08-18T17:03:07Z

Mark this page as obsolete and redirect to new location.

← Older revision		Revision as of 17:03, 18 August 2023
Line 1:		Line 1:
			'''IMPORTANT: This page is now obsolete and will be emptied soon. It's contents have been integrated in https://docs.yoctoproject.org/next/contributor-guide/index.html. Please contribute to this document instead.'''

	OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.		OpenEmbedded welcomes contributions. Before submitting a patch however there are a few things to keep in mind.

Vmeson: Add git send-email format for subject prefix for branches

2023-08-03T20:10:00Z

Add git send-email format for subject prefix for branches

← Older revision		Revision as of 20:10, 3 August 2023
Line 96:		Line 96:

	Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)		Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

			Additionally for released branches, please add the branch name (such as dunfell, kirkstone, mickledore, ...) to the prefix:
			--subject-prefix="mickledore][meta-oe][PATCH"

	==== Sending via a pull request ====		==== Sending via a pull request ====

Vmeson: Note that patches get merged without notification

2023-08-01T21:47:17Z

Note that patches get merged without notification

← Older revision		Revision as of 21:47, 1 August 2023
Line 133:		Line 133:
	If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.		If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.

	If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.		If your patch has not had any feedback in a day or two it may have already been merged so do a git pull on your branch to check on that. Note that many if not most layer maintainers do '''not''' send out acknowledgement emails if the patch is accepted. Alternatively, if there is no response or merge after a few days the patch may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. NOTE: patch review for feature / recipe upgrade patches will likely be delayed during a feature freeze because these types of patches aren't merged during this time - you may have to wait until after the freeze is lifted.

	== Appendix ==		== Appendix ==

Michael Opdenacker: /* Fixing your From identity */ Clarify that we are adding another "From" field

2023-05-09T08:55:18Z

Fixing your From identity: Clarify that we are adding another "From" field

← Older revision		Revision as of 08:55, 9 May 2023
Line 64:		Line 64:

	This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.		This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.
	The following will ensure that your e-mails have ~~a correct~~ <code>From</code> field, and that maintainers accepting your patches don't have to fix commit author information manually:		The following will ensure that your e-mails have an additional <code>From</code> field at the beginning of the e-mail body, and that maintainers accepting your patches don't have to fix commit author information manually:

	git config --global sendemail.from "linus.torvalds@kernel.org"		git config --global sendemail.from "linus.torvalds@kernel.org"

RossBurton: /* Fixing your From identity */

2023-05-03T16:52:53Z

Fixing your From identity

← Older revision		Revision as of 16:52, 3 May 2023
Line 67:		Line 67:

	git config --global sendemail.from "linus.torvalds@kernel.org"		git config --global sendemail.from "linus.torvalds@kernel.org"

			The sendemail.from field should be just your email address, which forces Git to add an explicit From field in the body of the patch.

	==== Configuring git send-email ====		==== Configuring git send-email ====

Michael Opdenacker: /* A task-oriented guide to creating a patch */ Further clarification of e-mail configuration instructions

2023-02-20T17:43:56Z

A task-oriented guide to creating a patch: Further clarification of e-mail configuration instructions

@@ Line 67: / Line 67: @@
   git config --global sendemail.from "linus.torvalds@kernel.org"
 ==== Sending using git-send-email ====
@@ Line 80: / Line 94: @@
 Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)
 ==== Sending via a pull request ====

Michael Opdenacker: /* Sending patches */ Improving e-mail sending instructions

2023-02-20T17:33:39Z

Sending patches: Improving e-mail sending instructions

← Older revision		Revision as of 17:33, 20 February 2023
Line 55:		Line 55:
	There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.		There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

	==== ~~Sending using git-send-email~~ ====		==== Fixing your From identity ====

			If you choose the first method: submitting your patches via e-mail.

	We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:		We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:
Line 66:		Line 68:
	git config --global sendemail.from "linus.torvalds@kernel.org"		git config --global sendemail.from "linus.torvalds@kernel.org"

	~~Here are settings for sending your e-mails through Google Mail's SMTP server:~~		==== Sending using git-send-email ====

	~~git config --global sendemail.smtpserver smtp.gmail.com~~
	~~git config --global sendemail.smtpserverport 587~~
	~~git config --global sendemail.smtpencryption tls~~
	git ~~config~~ -~~-global sendemail.smtpuser ada.lovelace@gmail.com~~

	~~You can use <code>git~~ send-email</code>'s <code>--envelope-sender</code> option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the Gmail settings tab. Use the Send mail as selection to address you want to send email from.

	To send just the top commit on your current branch (substitute mailing list address as appropriate):		To send just the top commit on your current branch (substitute mailing list address as appropriate):
Line 85:		Line 80:

	Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)		Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

			==== Settings for Gmail users ====

			Here are settings for sending your e-mails through Google Mail's SMTP server:

			git config --global sendemail.smtpserver smtp.gmail.com
			git config --global sendemail.smtpserverport 587
			git config --global sendemail.smtpencryption tls
			git config --global sendemail.smtpuser ada.lovelace@gmail.com

			You can use <code>git send-email</code>'s <code>--envelope-sender</code> option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the Gmail settings tab. Use the Send mail as selection to address you want to send email from.

	==== Sending via a pull request ====		==== Sending via a pull request ====
Line 99:		Line 105:
	===== Request OE contrib Write Access =====		===== Request OE contrib Write Access =====

	~~please~~ send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:		Please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] and:
	# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.		# Attach your ssh '''public''' key which usually named id_rsa.pub. If you don't have one generate it by running <tt>ssh-keygen -t rsa -b 4096 -C "your_email@example.com"</tt>.
	# List the repositories you're planning to contribute to.		# List the repositories you're planning to contribute to.

Michael Opdenacker: /* Sending using git-send-email */ Explain why we're advising to set "sendemail.from"

2023-02-20T17:12:20Z

Sending using git-send-email: Explain why we're advising to set "sendemail.from"

← Older revision		Revision as of 17:12, 20 February 2023
Line 57:		Line 57:
	==== Sending using git-send-email ====		==== Sending using git-send-email ====

	~~The following will ensure that your e-mails~~ have a ~~correct~~ <code>From</code> field~~. This field is used by~~ <code>~~git am~~</code> ~~to recreate commits~~ with ~~the right author name~~.		We have a frequent issue with contributors whose patches are received through a <code>From</code> field which doesn't match the <code>Signed-off-by</code> information. Here is a typical example for people sending from a domain name with [https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html DMARC]:

	git config --global sendemail.from "~~ada~~.~~lovelace~~@~~gmail~~.~~com~~"		From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"

			This field <code>From</code> field is used by <code>git am</code> to recreate commits with the right author name.
			The following will ensure that your e-mails have a correct <code>From</code> field, and that maintainers accepting your patches don't have to fix commit author information manually:

			git config --global sendemail.from "linus.torvalds@kernel.org"

	Here are settings for sending your e-mails through Google Mail's SMTP server:		Here are settings for sending your e-mails through Google Mail's SMTP server:

Rpcme: /* Community review */

2023-02-19T15:36:40Z

Community review

← Older revision		Revision as of 15:36, 19 February 2023
Line 113:		Line 113:
	== Community review ==		== Community review ==

	Your patch will be sent to the mailing list and for some layers should be immediately visible on ~~http~~://~~patches~~.~~openembedded~~.org/		Your patch will be sent to the mailing list and for some layers should be immediately visible on https://patchwork.yoctoproject.org/

	If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.		If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use <code>--subject-prefix="PATCH v2"</code>, v3, v4 etc. to mark the patch iteration. Please also '''test your revised changes''' - in particular don't just edit the patch file written out by git-format-patch and resend it.