Re: [RFD] Explicitly documenting patch submission

From: Dave Jones (davej_at_redhat.com)
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 19:02:25 +0100
    To: Ben Collins <bcollins@debian.org>
    
    

    On Tue, May 25, 2004 at 01:18:05PM -0400, Ben Collins wrote:

    > 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).

    For trivial one liners, it's usually quicker for me to
    just hack the file myself than to save the diff, run it through
    patch, delete the diff when I'm done etc. When I do this
    I usually put in the changelog "pointed out by Joe Hacker".
    My reasoning behind this is that all typos are then mine 8-)
    whilst still crediting the person who did the original.

    Likewise if I fix something in a slightly different way
    to how the patch that was submitted did it, as the person
    reporting still did some work which they should be credited for,
    even if ultimately their solution wasn't used, but was used
    as a basis for the real fix.

    In these cases, I think it'd be reasonable to have..

    Signed-off-by: Dave Jones <davej@redhat.com>
    Spotted-by: Joe Hacker <joe@scoblows.com>

    As asking submitters to sign off on modified versions
    of their patch would be silly overhead IMO.

    Linus?

                    Dave

    -
    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

    • Re: [patch 2.6.12-rc2] revert fs/char_dev.c CONFIG_BASE_FULL change
      ... > a patch from Matt Mackall that misbehaves. ... I actually asked Linus to revert it right ... I've got a Real Fix (a refactor of block and chardev name ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.9-rc3-mm3
      ... enable_irqwhen the interrupt enable depth is already 0. ... The maintainer added this call as part of a patch ... indicator that a real fix is pending. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: new asm-offsets.h patch problems
      ... With this patch applied ... Did you actually look at the output of the compile? ... The only real fix is to fix the dependencies or provide ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.13-rc7-git2 crashes on iBook
      ... > Stelian Pop wrote: ... It must be my bad english but I wasn't implying that the patch was ... However, a different fix (a real fix, not the workaround proposed above) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [parisc-linux] Re: [PATCH 3/9] mm: parisc pte atomicity
      ... using your own tmpalias area sounds much better than getting ... I've simply not wrapped my head around the races, ... it looks like we agree that my patch is necessary and valid as is; ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)