Message ID | 1344545493-6820-1-git-send-email-mcgrof@do-not-panic.com |
---|---|
State | Not Applicable, archived |
Delegated to: | David Miller |
Headers | show |
On Thu, Aug 9, 2012 at 10:51 PM, Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote: > of a second patch submission must supply their own Siged-off-by Signed-off-by > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -366,6 +366,21 @@ and protect the submitter from complaints. Note that under no circumstances > can you change the author's identity (the From header), as it is the one > which appears in the changelog. > > +If you are submitting a large change (for example a new driver) at times > +you may be asked to make quite a lot of modifications prior to getting > +your change accepted. At times you may even receive patches from developers > +who not only wish to tell you what you should change to get your changes > +upstream but actually send you patches. If those patches were made publicly > +and they do contain a Singed-off-by tag you are not expected to provide Signed-off-by > +their own Singed-off-by tag on the second iteration of the patch so long idem > +as there is a public record somewhere that can be used to show the > +contributor had sent their changes with their own Singed-off-by tag. ditto Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 9, 2012 at 1:58 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Aug 9, 2012 at 10:51 PM, Luis R. Rodriguez > <mcgrof@do-not-panic.com> wrote: >> of a second patch submission must supply their own Siged-off-by > > Signed-off-by will send a v2. Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/08/12 06:51, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> > > Initial large code submissions typically are not accepted > on their first patch submission. The developers are > typically given feedback and at times some developers may > even submit changes to the original authors for integration > into their second submission attempt. > > Developers wishing to contribute changes to the evolution > of a second patch submission must supply their own Siged-off-by > tag to the original authors and must submit their changes > on a public mailing list or ensure that these submission > are recorded somewhere publicly. > > To date a few of these type of contributors have expressed > different preferences for whether or not their own SOB tag > should be used for a second code submission. Lets keep things > simple and only require the contributor's SOB tag if so desired > explicitly. It is not technically required if there already > is a public record of their contribution somewhere. > > Document this on Documentation/SubmittingPatches > > Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> > --- > Documentation/SubmittingPatches | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index c379a2a..e018043 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -366,6 +366,21 @@ and protect the submitter from complaints. Note that under no circumstances > can you change the author's identity (the From header), as it is the one > which appears in the changelog. > > +If you are submitting a large change (for example a new driver) at times > +you may be asked to make quite a lot of modifications prior to getting > +your change accepted. This applies to any patch, not just large ones and/or drivers. > At times you may even receive patches from developers > +who not only wish to tell you what you should change to get your changes > +upstream but actually send you patches. This sentence is long and confusing. Perhaps something like: "Other developers may send patches to show what changes should be made, rather than just making comments". > If those patches were made publicly > +and they do contain a Singed-off-by tag you are not expected to provide > +their own Singed-off-by tag on the second iteration of the patch so long > +as there is a public record somewhere that can be used to show the > +contributor had sent their changes with their own Singed-off-by tag. If another developer sends a patch with a Signed-off-by, regardless of whether it is a patch against mainline, or a patch on top of a patch, why would you not be required to keep the Signed-off-by tag? Does this mean that I can review somebodies else's patch, send them a patch on top of it with my Signed-off-by, and they can simply drop it and take my work uncredited? If a developer wants to provided patches on top of someone else's work, but does not want to be credited with a Signed-off-by, then surely they should just not sign-off their patch? You also misspelled "Signed-of-by" several times. > + > +If you receive patches privately during development you may want to > +ask for these patches to be re-posted publicly or you can also decide > +to merge the patches as part of a separate historical git tree that > +will remain online for historical archiving. I don't think this necessarily needs to be stated. Lots of patches, especially drivers, have probably had several authors, but only require the sign-off of the person doing the actual submission. So the rules should be (IMHO): 1) The person submitting the code must sign the patch off. 2) If another person contributes to the code, whether during development, or as part of a review, then they should have a Signed-off-by tag applied only if they provide one. 3) Signed-off-by tags (all tags really) should never be added without the express permission of the person themselves. If additional credit needs to be given, but the creditor doesn't want to provide a Signed-off-by then one of the other tags could be used (such as Reviewed-by), or the person could be mentioned in the changelog perhaps? e.g: "Parts of the foo function provided by Joe Bloggs <joe@bloggs.com>" ~Ryan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I think it would be nice to have another tag for people who fix bugs in the original patch. The Reviewed-by tag implies approval of the whole patch and anyway reviewers don't normally comment unless they see a bug. Maybe something like: Contributor: Your Name <email@address.com> So the tags for developers would be: Signed-off-by: The patch went through you. Legal responsibility. Acked-by: You know what you are talking about and approve. Reviewed-by: You reviewed the patch and approve. Contributor: You noticed or fixed a bug in the patch. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a..e018043 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -366,6 +366,21 @@ and protect the submitter from complaints. Note that under no circumstances can you change the author's identity (the From header), as it is the one which appears in the changelog. +If you are submitting a large change (for example a new driver) at times +you may be asked to make quite a lot of modifications prior to getting +your change accepted. At times you may even receive patches from developers +who not only wish to tell you what you should change to get your changes +upstream but actually send you patches. If those patches were made publicly +and they do contain a Singed-off-by tag you are not expected to provide +their own Singed-off-by tag on the second iteration of the patch so long +as there is a public record somewhere that can be used to show the +contributor had sent their changes with their own Singed-off-by tag. + +If you receive patches privately during development you may want to +ask for these patches to be re-posted publicly or you can also decide +to merge the patches as part of a separate historical git tree that +will remain online for historical archiving. + Special note to back-porters: It seems to be a common and useful practise to insert an indication of the origin of a patch at the top of the commit message (just after the subject line) to facilitate tracking. For instance,