Re: [RFD] Explicitly documenting patch submission

From: Larry McVoy (lm_at_bitmover.com)
Date: 05/27/04

  • Next message: Andrea Arcangeli: "Re: 4k stacks in 2.6" 
    Date:	Thu, 27 May 2004 07:51:27 -0700
To: Andrew Morton <akpm@osdl.org>

    On Thu, May 27, 2004 at 01:04:09AM -0700, Andrew Morton wrote:
    > Larry McVoy <lm@bitmover.com> wrote:
    > >
    > > I just read the whole thread and I can't help but wonder if you aren't
    > > trying to solve the 5% problem while avoiding the 95% problem. Right now,
    > > because of how patches are fanned in through maintainers, lots and lots
    > > of patches are going into the SCM system (BK and/or CVS since that is
    > > derived from BK) as authored by a handful of people. Just go look at
    > > the stats: http://linux.bkbits.net:8080/linux-2.5/stats?nav=index.html
    > > As productive as Andrew is I find it difficult to believe he has
    > > personally authored more than 5000 patches. He hasn't, he doesn't
    > > pretend to have done so but we are not getting the authorship right.
    >
    > Numerous people have asked Linus to make that small change to his scripts
    > but he prefers it the way it is, because the current practice better
    > represents how the patch got into the tree. The authors names are in the
    > changelog and the submitter's name is in the SCM metadata.

    That means that all the SCM tools, BK, CVS, whatever, get the wrong attribution
    when you are trying to track down a bug. Which is more important when you are
    debugging: knowing who created the change or who pushed the change to Linus?

    The high order bit, in my not humble opinion, is the author. If Linus wants
    to keep the info about the submitter then do that in the check in comments.

    > A purist would say "that should have been a separate changeset" but I
    > disagree - I'd prefer that the patch which hits the tree is a single,
    > complete, logical whole. Because the quality and integrity of the
    > changeset is more important than precisely tracking the little fixes which
    > got added on the way through.

    I think we can have our cake and eat it too, at least in BK (and there
    is no reason other systems couldn't do this as well): BK does not have
    the concept of a 1:1 binding between a change to a file and a changeset.
    A changeset is a container which may have one or more deltas to one or
    more files, i.e., it is many:1.

    If you took to sending your patches as the original patch plus another
    patch, bundling them together (I can work out a format and GPLed tools for
    this) then what we could do is have the BK import tools record the first
    one as a set of deltas, the next one as another set of deltas, and so on.
    We can handle an arbitrary number of patches to patches to patches.
    Then when the import finishes we bundle up all the deltas in one logical
    changeset. 99% of the time people won't care about the details, when
    they are looking through the code the interfaces will all work as they
    do today, the BK/Web interface would export this as a patch just like
    you are used to, but when people do care the full information is there.

    I suspect that with a little practice this could be quite useful.
    I could build tools which record the secondary patches as diffs to
    the patches (I think) and if you have ever read a diff of a diff
    it is suprisingly useful. I tend to save diffs of my work in
    progress and then later I'll generate diffs again and diff them to
    get my context back. 

    -- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.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: Andrea Arcangeli: "Re: 4k stacks in 2.6"

    Relevant Pages

    • Re: [RFD] Explicitly documenting patch submission
      ... > If you took to sending your patches as the original patch plus another ... > one as a set of deltas, the next one as another set of deltas, and so on. ... > We can handle an arbitrary number of patches to patches to patches. ... > I could build tools which record the secondary patches as diffs to ...
      (Linux-Kernel)
    • Re: startssl at boot time
      ... > just install the port as is and hope that all the patches are added. ... You don't even need to edit the saved message to extract the patch ... occasionally known as 'diffs'. ... format is not the 'unidiff' format that basically everyone uses: ...
      (freebsd-questions)
    • Re: [RFD] Explicitly documenting patch submission
      ... > I could build tools which record the secondary patches as diffs to ... The gives a perfect audit trail back to who authored each line. ... Another problem is that you need a central key repository. ...
      (Linux-Kernel)
    • Re: [PATCH 1/3] mm: rename kmem_cache_s to kmem_cache
      ... Well I stared at these diffs for a long time. ... of value to the kernel and they do risk breaking other people's patches. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Do I need a versioning system or how to organize my work?
      ... compiled and created patches from diffs between the local files and ... the remove CVS. ... That led to problems when working on various patches for various bugs ... I could set up my own VCS with various branches one for each patch I'm ...
      (comp.os.linux.development.apps)