Re: [RFD] Explicitly documenting patch submission

From: Ben Collins (bcollins_at_debian.org)
Date: 05/25/04

  • Next message: Linus Torvalds: "Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE"
    Date:	Tue, 25 May 2004 13:18:05 -0400
    To: Linus Torvalds <torvalds@osdl.org>
    
    

    On Tue, May 25, 2004 at 10:15:15AM -0700, Linus Torvalds wrote:
    >
    >
    > On Tue, 25 May 2004, Ben Collins wrote:
    > >
    > > I've got a question about this. A lot of times I get patches that are
    > > just one/two-liners and the explanation is somewhat self-explantory,
    > > etc. Say the patch comes to me from some patch collection maintainer,
    > > who got it from the original author.
    > >
    > > So the original person never put a Signed-off-by, and neither did the
    > > person who sent me the patch, should I still add the eplicit
    > > Signed-off-by's to the patch, and add myself, before sending it to you?
    >
    > You should never sign off for somebody else.
    >
    > You _can_ sign off as yourself, and just add a note of "From xxxx". That's
    > what the (b) case is all about (ie "to the best of my knowledge it's
    > already under a open-source license").
    >
    > Of course, if it's a _big_ work with lots of original content, and you're
    > unsure of exactly what the original author wanted to do with this, you
    > obviously should _not_ sign off on it. But you knew that.

    I know you want this simple, but should we keep the paper-trail momentum
    going by adding a "Submitted-by"? Like if I get a one-liner fix, which
    is obviously not adding new code, rather than go through the whole
    process of asking for them to agree to the signoff deal, could I do:

    Submitted-by: Jimmy Janitor <jimmy@janitor.blah>
    Signed-off-by: Ben Collins <bcollins@debian.org>

    ? I like the idea of knowing where a patch came from and via who. This
    would make it easier to analyze that info, but keep it simple for
    trivial patches that so many of us get (in the (b) case).

    -- 
    Debian     - http://www.debian.org/
    Linux 1394 - http://www.linux1394.org/
    Subversion - http://subversion.tigris.org/
    WatchGuard - http://www.watchguard.com/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Linus Torvalds: "Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE"

    Relevant Pages

    • 9_Recommended error codes (specifically return code 5)
      ... * "return code 2" indicates patches are already installed. ... * "return code 25" means a patches requires another patch that is not yet installed. ... With or without using the save option, the patch installation process ... Installing 114008-01... ...
      (SunManagers)
    • Re: [PATCH] clarify message and give support contact for non-GPL modules
      ... The author of the second module ... So here is another attempt at the patch. ... send the line "unsubscribe linux-kernel" in ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
      (Linux-Kernel)
    • Re: Fw: [PATCH 1/1] file capabilities: simplify signal check
      ... Oh, sorry, I got lost in the set of patches in the message. ... CONFIG_SECURITY_FILE_CAPABLITIES appears to be deny killing processes ... Subject: [PATCH 1/1] file capabilities: simplify signal check ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
      (Linux-Kernel)
    • SUCCESS Re: 2.6.0-test11-mm1
      ... patch that's responsible, but it'd take a month to find out anything ... conclusive -- ten reboots, two days of stress testing each in order to ... I've stored a Bitkeeper archive of the -mm1 patches (one changeset per ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] HOWTO do Linux kernel development
      ... IMHO it's ok to submit patches that are not perfect, ... > Justify your change ... My request is that each patch should carry a meaningful changelog. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)