Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
nd a new +driver which uses that new API, separate those into two commits. On the other hand, if you make a single change to numerous files, -group those changes into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single commit. Thus a single logical change +is contained within a single commit. -If one patch depends on another patch in order for a change to be -complete, that is OK. Simply note "this patch depends on patch X" -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note "this commit depends on commit X" +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +112,41 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) "git format-patch" + +Now you need to prepare your patches for e-mail submission. +Use "git format-patch origin" to extract all commits which have been applied, +but are not yet in the origin repository. +Alternatively use "git format-patch -20" to extract the last 20 patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + +Read the manpages of "git format-patch". +Specially the options "--cover-letter" and "--subject-prefix='PATCH v4'" +come handy. + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -163,9 +163,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is . +Linux kernel. His e-mail address is . He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. Patches which are bug fixes, are "obvious" changes, or similarly require little discussion should be sent or CC'd to Linus. Patches @@ -175,7 +175,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +216,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +239,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +250,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +260,7 @@ Linus will not apply it. -10) Don't get discouraged.
Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
those changes into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single commit. Thus a single logical change +is contained within a single commit. -If one patch depends on another patch in order for a change to be -complete, that is OK. Simply note this patch depends on patch X -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note this commit depends on commit X +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +112,41 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) git format-patch + +Now you need to prepare your patches for e-mail submission. +Use git format-patch origin to extract all commits which have been applied, +but are not yet in the origin repository. +Alternatively use git format-patch -20 to extract the last 20 patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller stefanbel...@googlemail.com +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + +Read the manpages of git format-patch. +Specially the options --cover-letter and --subject-prefix='PATCH v4' +come handy. + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -163,9 +163,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is torva...@linux-foundation.org. +Linux kernel. His e-mail address is torva...@linux-foundation.org. He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. Patches which are bug fixes, are obvious changes, or similarly require little discussion should be sent or CC'd to Linus. Patches @@ -175,7 +175,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +216,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +239,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +250,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +260,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +11) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
Stefan Beller writes: > +5) "git format-patch HEAD~n" > + > +Use "git format-patch HEAD~n" to extract the last n patches from your > +git repository. They will be be saved in textfiles named > + > +0001-Introduce-new-Feature.patch > +0002-Improve-Documentation.patch Two comments and a half-nit. - "--subject-prefix='PATCH v4'" is handy to know (since the workflow already assumes reviews and resubmissions in #11). - "--cover-letter" is handy to know when sending a multi-patch series. - "git format-patch -20" or "git format-patch origin" might be more familiar looking form than "git format-patch HEAD~20". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
Stefan Beller stefanbel...@googlemail.com writes: +5) git format-patch HEAD~n + +Use git format-patch HEAD~n to extract the last n patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch Two comments and a half-nit. - --subject-prefix='PATCH v4' is handy to know (since the workflow already assumes reviews and resubmissions in #11). - --cover-letter is handy to know when sending a multi-patch series. - git format-patch -20 or git format-patch origin might be more familiar looking form than git format-patch HEAD~20. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
On 07/23/2012 12:20 AM, Stefan Beller wrote: > On 07/23/2012 06:45 AM, Randy Dunlap wrote: > >> On 07/22/2012 12:56 AM, Stefan Beller wrote: >> >>> Documentation/SubmittingPatches | 191 >>> >>> 1 file changed, 116 insertions(+), 75 deletions(-) >>> >>> diff --git a/Documentation/SubmittingPatches >>> b/Documentation/SubmittingPatches >>> index c379a2a..ac00451 100644 >>> --- a/Documentation/SubmittingPatches >>> +++ b/Documentation/SubmittingPatches >>> @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger >>> mailing lists!!! >>> Linus Torvalds is the final arbiter of all changes accepted into the >>> -Linux kernel. His e-mail address is . >>> +Linux kernel. His e-mail address is . >> >> what are the changes on the line above and below, please? >> >>> He gets a lot of e-mail, so typically you should do your best to -avoid- >>> -sending him e-mail. >>> +sending him e-mail. >> >> >> >> thanks, >> > There used to be a whitespace after each of both lines, but my mailprogram > removed them, so in > the actually sent patch they seem to be equal. :/ > then you'll probably need to resend the patch so that it will apply cleanly, but that's up to whoever is going to apply/merge it. thanks, -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
On 07/23/2012 06:45 AM, Randy Dunlap wrote: On 07/22/2012 12:56 AM, Stefan Beller wrote: Documentation/SubmittingPatches | 191 1 file changed, 116 insertions(+), 75 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a..ac00451 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is . +Linux kernel. His e-mail address is . what are the changes on the line above and below, please? He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. thanks, There used to be a whitespace after each of both lines, but my mailprogram removed them, so in the actually sent patch they seem to be equal. :/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
On 07/23/2012 06:45 AM, Randy Dunlap wrote: On 07/22/2012 12:56 AM, Stefan Beller wrote: Documentation/SubmittingPatches | 191 1 file changed, 116 insertions(+), 75 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a..ac00451 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is torva...@linux-foundation.org. +Linux kernel. His e-mail address is torva...@linux-foundation.org. what are the changes on the line above and below, please? He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. thanks, There used to be a whitespace after each of both lines, but my mailprogram removed them, so in the actually sent patch they seem to be equal. :/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
On 07/23/2012 12:20 AM, Stefan Beller wrote: On 07/23/2012 06:45 AM, Randy Dunlap wrote: On 07/22/2012 12:56 AM, Stefan Beller wrote: Documentation/SubmittingPatches | 191 1 file changed, 116 insertions(+), 75 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a..ac00451 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is torva...@linux-foundation.org. +Linux kernel. His e-mail address is torva...@linux-foundation.org. what are the changes on the line above and below, please? He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. thanks, There used to be a whitespace after each of both lines, but my mailprogram removed them, so in the actually sent patch they seem to be equal. :/ then you'll probably need to resend the patch so that it will apply cleanly, but that's up to whoever is going to apply/merge it. thanks, -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
On 07/22/2012 12:56 AM, Stefan Beller wrote: > Documentation/SubmittingPatches | 191 > > 1 file changed, 116 insertions(+), 75 deletions(-) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index c379a2a..ac00451 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger > mailing lists!!! > Linus Torvalds is the final arbiter of all changes accepted into the > -Linux kernel. His e-mail address is . > +Linux kernel. His e-mail address is . what are the changes on the line above and below, please? > He gets a lot of e-mail, so typically you should do your best to -avoid- > -sending him e-mail. > +sending him e-mail. thanks, -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
r changes include an API update, and a new +driver which uses that new API, separate those into two commits. On the other hand, if you make a single change to numerous files, -group those changes into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single commit. Thus a single logical change +is contained within a single commit. -If one patch depends on another patch in order for a change to be -complete, that is OK. Simply note "this patch depends on patch X" -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note "this commit depends on commit X" +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +112,35 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) "git format-patch HEAD~n" + +Use "git format-patch HEAD~n" to extract the last n patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is . +Linux kernel. His e-mail address is . He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. Patches which are bug fixes, are "obvious" changes, or similarly require little discussion should be sent or CC'd to Linus. Patches @@ -175,7 +169,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +210,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +233,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +244,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +254,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +11) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version @@ -276,8 +270,8 @@ That's the nature of the system. If he drops your patch, it could be due to * Your patch did not
[RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
, if you make a single change to numerous files, -group those changes into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single commit. Thus a single logical change +is contained within a single commit. -If one patch depends on another patch in order for a change to be -complete, that is OK. Simply note this patch depends on patch X -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note this commit depends on commit X +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +112,35 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) git format-patch HEAD~n + +Use git format-patch HEAD~n to extract the last n patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller stefanbel...@googlemail.com +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is torva...@linux-foundation.org. +Linux kernel. His e-mail address is torva...@linux-foundation.org. He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. Patches which are bug fixes, are obvious changes, or similarly require little discussion should be sent or CC'd to Linus. Patches @@ -175,7 +169,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +210,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +233,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +244,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +254,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +11) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version @@ -276,8 +270,8 @@ That's the nature of the system. If he drops your patch, it could be due to * Your patch did not apply cleanly to the latest kernel version. * Your patch was not sufficiently discussed on linux-kernel
Re: [RESEND][PATCH] Rewrite Documentation/SubmittingPatches.
On 07/22/2012 12:56 AM, Stefan Beller wrote: Documentation/SubmittingPatches | 191 1 file changed, 116 insertions(+), 75 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a..ac00451 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is torva...@linux-foundation.org. +Linux kernel. His e-mail address is torva...@linux-foundation.org. what are the changes on the line above and below, please? He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. thanks, -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On 07/15/2012 11:20 PM, Stefan Beller wrote: > Heh, > It seems as if googlemail is not a suited interface to contribute to linux. > > The raw patch (without clipped lines) can be found at > http://pastebin.com/raw.php?i=3QKRZz2M > > Stefan > > 2012/7/15 Rob Landley : >> On 07/13/2012 09:45 AM, Stefan Beller wrote: >>> This updates the documentation on how to create patches and send >>> these to the kernel mailing list. >>> >>> The documentation before was written in times before git was there, >>> so the crafting of the patch needed to be done manually by diff -up >>> in the right directory. >>> >>> This patch aims at simplifying the patch sending process, without >>> breaking the output results. >> >> This patch is whitespace damaged (wordwrapped at the @@ lines), which is >> either ironic or unfortunate. (After Alanis Morisette, I can't tell >> anymore.) >> >>> A discussion can be found at >>> https://plus.google.com/111049168280159033135/posts/ekAxK9achsA >>> >>> Signed-off-by: Stefan Beller >>> Acked-by: Jeff Garzik jgar...@pobox.com >> >> But other than that Jeff's objection was my big one, and that's >> addressed in v2, so: >> >> Acked-by: Rob Landley >> >> Rob >> -- Q1. Who is going to merge the patch? Rob or someone else? Q2. Are you (Stefan) going to send a patch that is mergeable? -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
Heh, It seems as if googlemail is not a suited interface to contribute to linux. The raw patch (without clipped lines) can be found at http://pastebin.com/raw.php?i=3QKRZz2M Stefan 2012/7/15 Rob Landley : > On 07/13/2012 09:45 AM, Stefan Beller wrote: >> This updates the documentation on how to create patches and send >> these to the kernel mailing list. >> >> The documentation before was written in times before git was there, >> so the crafting of the patch needed to be done manually by diff -up >> in the right directory. >> >> This patch aims at simplifying the patch sending process, without >> breaking the output results. > > This patch is whitespace damaged (wordwrapped at the @@ lines), which is > either ironic or unfortunate. (After Alanis Morisette, I can't tell > anymore.) > >> A discussion can be found at >> https://plus.google.com/111049168280159033135/posts/ekAxK9achsA >> >> Signed-off-by: Stefan Beller >> Acked-by: Jeff Garzik jgar...@pobox.com > > But other than that Jeff's objection was my big one, and that's > addressed in v2, so: > > Acked-by: Rob Landley > > Rob > -- > GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. > Either it's "mere aggregation", or a license violation. Pick one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
Heh, It seems as if googlemail is not a suited interface to contribute to linux. The raw patch (without clipped lines) can be found at http://pastebin.com/raw.php?i=3QKRZz2M Stefan 2012/7/15 Rob Landley r...@landley.net: On 07/13/2012 09:45 AM, Stefan Beller wrote: This updates the documentation on how to create patches and send these to the kernel mailing list. The documentation before was written in times before git was there, so the crafting of the patch needed to be done manually by diff -up in the right directory. This patch aims at simplifying the patch sending process, without breaking the output results. This patch is whitespace damaged (wordwrapped at the @@ lines), which is either ironic or unfortunate. (After Alanis Morisette, I can't tell anymore.) A discussion can be found at https://plus.google.com/111049168280159033135/posts/ekAxK9achsA Signed-off-by: Stefan Beller stefanbel...@googlemail.com Acked-by: Jeff Garzik jgar...@pobox.com But other than that Jeff's objection was my big one, and that's addressed in v2, so: Acked-by: Rob Landley r...@landley.net Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On 07/15/2012 11:20 PM, Stefan Beller wrote: Heh, It seems as if googlemail is not a suited interface to contribute to linux. The raw patch (without clipped lines) can be found at http://pastebin.com/raw.php?i=3QKRZz2M Stefan 2012/7/15 Rob Landley r...@landley.net: On 07/13/2012 09:45 AM, Stefan Beller wrote: This updates the documentation on how to create patches and send these to the kernel mailing list. The documentation before was written in times before git was there, so the crafting of the patch needed to be done manually by diff -up in the right directory. This patch aims at simplifying the patch sending process, without breaking the output results. This patch is whitespace damaged (wordwrapped at the @@ lines), which is either ironic or unfortunate. (After Alanis Morisette, I can't tell anymore.) A discussion can be found at https://plus.google.com/111049168280159033135/posts/ekAxK9achsA Signed-off-by: Stefan Beller stefanbel...@googlemail.com Acked-by: Jeff Garzik jgar...@pobox.com But other than that Jeff's objection was my big one, and that's addressed in v2, so: Acked-by: Rob Landley r...@landley.net Rob -- Q1. Who is going to merge the patch? Rob or someone else? Q2. Are you (Stefan) going to send a patch that is mergeable? -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On 07/13/2012 09:45 AM, Stefan Beller wrote: > This updates the documentation on how to create patches and send > these to the kernel mailing list. > > The documentation before was written in times before git was there, > so the crafting of the patch needed to be done manually by diff -up > in the right directory. > > This patch aims at simplifying the patch sending process, without > breaking the output results. This patch is whitespace damaged (wordwrapped at the @@ lines), which is either ironic or unfortunate. (After Alanis Morisette, I can't tell anymore.) > A discussion can be found at > https://plus.google.com/111049168280159033135/posts/ekAxK9achsA > > Signed-off-by: Stefan Beller > Acked-by: Jeff Garzik jgar...@pobox.com But other than that Jeff's objection was my big one, and that's addressed in v2, so: Acked-by: Rob Landley Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On 07/13/2012 09:45 AM, Stefan Beller wrote: This updates the documentation on how to create patches and send these to the kernel mailing list. The documentation before was written in times before git was there, so the crafting of the patch needed to be done manually by diff -up in the right directory. This patch aims at simplifying the patch sending process, without breaking the output results. This patch is whitespace damaged (wordwrapped at the @@ lines), which is either ironic or unfortunate. (After Alanis Morisette, I can't tell anymore.) A discussion can be found at https://plus.google.com/111049168280159033135/posts/ekAxK9achsA Signed-off-by: Stefan Beller stefanbel...@googlemail.com Acked-by: Jeff Garzik jgar...@pobox.com But other than that Jeff's objection was my big one, and that's addressed in v2, so: Acked-by: Rob Landley r...@landley.net Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Rewrite Documentation/SubmittingPatches.
h uses that new API, separate those into two commits. On the other hand, if you make a single change to numerous files, -group those changes into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single commit. Thus a single logical change +is contained within a single commit. -If one patch depends on another patch in order for a change to be -complete, that is OK. Simply note "this patch depends on patch X" -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note "this commit depends on commit X" +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +112,35 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) "git format-patch HEAD~n" + +Use "git format-patch HEAD~n" to extract the last n patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is . +Linux kernel. His e-mail address is . He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. Patches which are bug fixes, are "obvious" changes, or similarly require little discussion should be sent or CC'd to Linus. Patches @@ -175,7 +169,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +210,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +233,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +244,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +254,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +11) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version @@ -276,8 +270,8 @@ That's the nature of the system. If he drops your patch, it could be due to * Your patch did not apply cleanly to the latest kernel version. * Your patch was not sufficiently discussed on linux-kernel. -* A
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On Fri, Jul 13, 2012 at 7:51 AM, Stefan Beller wrote: > This updates the documentation on how to create patches and send > these to the kernel mailing list. > > The documentation before was written in times before git was there, > so the crafting of the patch needed to be done manually by diff -up > in the right directory. > > This patch aims at simplifying the patch sending process, without > breaking the output results. > > A discussion with gregkh can be found at > https://plus.google.com/111049168280159033135/posts/ekAxK9achsA > > Signed-off-by: Stefan Beller Speaking as the original author... seems reasonable. ACK with Borislav's suggested change, moving the old instructions to the bottom of the file. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On Fri, Jul 13, 2012 at 01:51:50PM +0200, Stefan Beller wrote:
> This updates the documentation on how to create patches and send
> these to the kernel mailing list.
>
> The documentation before was written in times before git was there,
> so the crafting of the patch needed to be done manually by diff -up
> in the right directory.
>
> This patch aims at simplifying the patch sending process, without
> breaking the output results.
>
> A discussion with gregkh can be found at
> https://plus.google.com/111049168280159033135/posts/ekAxK9achsA
>
> Signed-off-by: Stefan Beller
> ---
> Documentation/SubmittingPatches | 135
> ++-
> 1 files changed, 63 insertions(+), 72 deletions(-)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index c379a2a..966db54 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -22,55 +22,21 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
>
>
>
> -1) "diff -up"
> +1) Using git
>
>
> -Use "diff -up" or "diff -uprN" to create patches.
> +Use the distributed version control git to commit your changes
> +into your local git repository.
>
> -All changes to the Linux kernel occur in the form of patches, as
> -generated by diff(1). When creating your patch, make sure to create it
> -in "unified diff" format, as supplied by the '-u' argument to diff(1).
> -Also, please use the '-p' argument which shows which C function each
> -change is in - that makes the resultant diff a lot easier to read.
> -Patches should be based in the root kernel source directory,
> -not in any lower subdirectory.
> -
> -To create a patch for a single file, it is often sufficient to do:
> -
> - SRCTREE= linux-2.6
> - MYFILE= drivers/net/mydriver.c
> -
> - cd $SRCTREE
> - cp $MYFILE $MYFILE.orig
> - vi $MYFILE # make your change
> - cd ..
> - diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
> -
> -To create a patch for multiple files, you should unpack a "vanilla",
> -or unmodified kernel source tree, and generate a diff against your
> -own source tree. For example:
> -
> - MYSRC= /devel/linux-2.6
> -
> - tar xvfz linux-2.6.12.tar.gz
> - mv linux-2.6.12 linux-2.6.12-vanilla
> - diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
> - linux-2.6.12-vanilla $MYSRC > /tmp/patch
> -
> -"dontdiff" is a list of files which are generated by the kernel during
> -the build process, and should be ignored in any diff(1)-generated
> -patch. The "dontdiff" file is included in the kernel tree in
> -2.6.12 and later. For earlier kernel versions, you can get it
> -from .
> -
> -Make sure your patch does not include any extra files which do not
> -belong in a patch submission. Make sure to review your patch -after-
> -generated it with diff(1), to ensure accuracy.
Can we keep this at the end of the document and call it "Creating
patches - the obsolete way" or similar, as a backup for people who can't
use git for whatever reasons?
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Rewrite Documentation/SubmittingPatches.
ngle commit. Thus a single logical change +is contained within a single commit. -If one patch depends on another patch in order for a change to be -complete, that is OK. Simply note "this patch depends on patch X" -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note "this commit depends on commit X" +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +109,35 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) "git format-patch HEAD~n" + +Use "git format-patch HEAD~n" to extract the last n patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -175,7 +166,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +207,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +230,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +241,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +251,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +11) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version @@ -276,8 +267,8 @@ That's the nature of the system. If he drops your patch, it could be due to * Your patch did not apply cleanly to the latest kernel version. * Your patch was not sufficiently discussed on linux-kernel. -* A style issue (see section 2). -* An e-mail formatting issue (re-read this section). +* A style issue (see section #2, #3, #4). +* An e-mail formatting issue (re-read this section or section #8). * A technical problem with your change. * He gets tons of e-mail, and yours got lost in the shuffle. * You are being annoying. @@ -286,7 +277,7 @@ When in doubt, solicit comments on linux-kernel mailing list. -11) Include PATCH in the subject +12) Include PATCH in the subject Due to high e-mail traffic to Linus, and to linux-kernel, it is common convention to prefix your subject line with [PATCH]. This lets Linus @@ -295,7 +286,7 @@ e-mail discussions. -12) Sign your work +13) Sign your work To improve tracking of who did what, especially with pa
[PATCH] Rewrite Documentation/SubmittingPatches.
to be -complete, that is OK. Simply note this patch depends on patch X -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note this commit depends on commit X +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +109,35 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) git format-patch HEAD~n + +Use git format-patch HEAD~n to extract the last n patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller stefanbel...@googlemail.com +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -175,7 +166,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +207,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +230,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +241,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +251,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +11) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version @@ -276,8 +267,8 @@ That's the nature of the system. If he drops your patch, it could be due to * Your patch did not apply cleanly to the latest kernel version. * Your patch was not sufficiently discussed on linux-kernel. -* A style issue (see section 2). -* An e-mail formatting issue (re-read this section). +* A style issue (see section #2, #3, #4). +* An e-mail formatting issue (re-read this section or section #8). * A technical problem with your change. * He gets tons of e-mail, and yours got lost in the shuffle. * You are being annoying. @@ -286,7 +277,7 @@ When in doubt, solicit comments on linux-kernel mailing list. -11) Include PATCH in the subject +12) Include PATCH in the subject Due to high e-mail traffic to Linus, and to linux-kernel, it is common convention to prefix your subject line with [PATCH]. This lets Linus @@ -295,7 +286,7 @@ e-mail discussions. -12) Sign your work +13) Sign your work To improve tracking of who did what, especially with patches that can percolate to their final resting place in the kernel through several @@ -390,7 +381,7 @@ tracking your trees, and to people trying to trouble-shoot bugs
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On Fri, Jul 13, 2012 at 01:51:50PM +0200, Stefan Beller wrote:
This updates the documentation on how to create patches and send
these to the kernel mailing list.
The documentation before was written in times before git was there,
so the crafting of the patch needed to be done manually by diff -up
in the right directory.
This patch aims at simplifying the patch sending process, without
breaking the output results.
A discussion with gregkh can be found at
https://plus.google.com/111049168280159033135/posts/ekAxK9achsA
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Documentation/SubmittingPatches | 135
++-
1 files changed, 63 insertions(+), 72 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c379a2a..966db54 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -22,55 +22,21 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
-1) diff -up
+1) Using git
-Use diff -up or diff -uprN to create patches.
+Use the distributed version control git to commit your changes
+into your local git repository.
-All changes to the Linux kernel occur in the form of patches, as
-generated by diff(1). When creating your patch, make sure to create it
-in unified diff format, as supplied by the '-u' argument to diff(1).
-Also, please use the '-p' argument which shows which C function each
-change is in - that makes the resultant diff a lot easier to read.
-Patches should be based in the root kernel source directory,
-not in any lower subdirectory.
-
-To create a patch for a single file, it is often sufficient to do:
-
- SRCTREE= linux-2.6
- MYFILE= drivers/net/mydriver.c
-
- cd $SRCTREE
- cp $MYFILE $MYFILE.orig
- vi $MYFILE # make your change
- cd ..
- diff -up $SRCTREE/$MYFILE{.orig,} /tmp/patch
-
-To create a patch for multiple files, you should unpack a vanilla,
-or unmodified kernel source tree, and generate a diff against your
-own source tree. For example:
-
- MYSRC= /devel/linux-2.6
-
- tar xvfz linux-2.6.12.tar.gz
- mv linux-2.6.12 linux-2.6.12-vanilla
- diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
- linux-2.6.12-vanilla $MYSRC /tmp/patch
-
-dontdiff is a list of files which are generated by the kernel during
-the build process, and should be ignored in any diff(1)-generated
-patch. The dontdiff file is included in the kernel tree in
-2.6.12 and later. For earlier kernel versions, you can get it
-from http://www.xenotime.net/linux/doc/dontdiff.
-
-Make sure your patch does not include any extra files which do not
-belong in a patch submission. Make sure to review your patch -after-
-generated it with diff(1), to ensure accuracy.
Can we keep this at the end of the document and call it Creating
patches - the obsolete way or similar, as a backup for people who can't
use git for whatever reasons?
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rewrite Documentation/SubmittingPatches.
On Fri, Jul 13, 2012 at 7:51 AM, Stefan Beller stefanbel...@googlemail.com wrote: This updates the documentation on how to create patches and send these to the kernel mailing list. The documentation before was written in times before git was there, so the crafting of the patch needed to be done manually by diff -up in the right directory. This patch aims at simplifying the patch sending process, without breaking the output results. A discussion with gregkh can be found at https://plus.google.com/111049168280159033135/posts/ekAxK9achsA Signed-off-by: Stefan Beller stefanbel...@googlemail.com Speaking as the original author... seems reasonable. ACK with Borislav's suggested change, moving the old instructions to the bottom of the file. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Rewrite Documentation/SubmittingPatches.
into a single patch. Thus a single logical change -is contained within a single patch. +group those changes into a single commit. Thus a single logical change +is contained within a single commit. -If one patch depends on another patch in order for a change to be -complete, that is OK. Simply note this patch depends on patch X -in your patch description. +If one commit depends on another commit in order for a change to be +complete, that is OK. Simply note this commit depends on commit X +in your commit description. -If you cannot condense your patch set into a smaller set of patches, +If you cannot condense your commit set into a smaller set of commits, then only post say 15 or so at a time and wait for review and integration. 4) Style check your changes. -Check your patch for basic style violations, details of which can be +Check your commit for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probably +the reviewers time and will get your commit rejected, probably without even being read. At a minimum you should check your patches with the patch style @@ -146,7 +112,35 @@ be able to justify all violations that remain in your patch. -5) Select e-mail destination. +5) git format-patch HEAD~n + +Use git format-patch HEAD~n to extract the last n patches from your +git repository. They will be be saved in textfiles named + +0001-Introduce-new-Feature.patch +0002-Improve-Documentation.patch + +The first lines of such a file might look like + +1 From d39e331c30cb563fd152f484f7ca1d14dc98d57e Mon Sep 17 00:00:00 2001 +2 From: Stefan Beller stefanbel...@googlemail.com +3 Date: Fri, 13 Jul 2012 12:55:54 +0200 +4 Subject: [PATCH] Rewrite Documentation/SubmittingPatches. +5 +6 This updates the documentation on how to create patches and send +7 these to the kernel mailing list. +8 ... + +Take the body of these files starting from line 6 as your email body and +as email subject choose the subject as in line 4. +In this example case the subject would be +[PATCH] Rewrite Documentation/SubmittingPatches. + +For further formatting of the email, +see #8 (No MIME, no links, no compression, no attachments. Just plain text.) + + +6) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -163,9 +157,9 @@ Do not send more than 15 patches at once to the vger mailing lists!!! Linus Torvalds is the final arbiter of all changes accepted into the -Linux kernel. His e-mail address is torva...@linux-foundation.org. +Linux kernel. His e-mail address is torva...@linux-foundation.org. He gets a lot of e-mail, so typically you should do your best to -avoid- -sending him e-mail. +sending him e-mail. Patches which are bug fixes, are obvious changes, or similarly require little discussion should be sent or CC'd to Linus. Patches @@ -175,7 +169,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +7) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -216,7 +210,7 @@ Trivial patches must qualify for one of the following rules: -7) No MIME, no links, no compression, no attachments. Just plain text. +8) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -239,9 +233,9 @@ you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. -8) E-mail size. +9) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #8. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 300 kB in size, @@ -250,7 +244,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +10) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -260,7 +254,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +11) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version @@ -276,8 +270,8 @@ That's the nature of the system. If he drops your patch, it could be due to * Your patch did not apply cleanly to the latest kernel version. * Your patch was not sufficiently discussed on linux-kernel. -* A style issue (see section 2). -* An e-mail formatting issue (re-read this section). +* A style issue (see section #2, #3
