Re: [RFD] Explicitly documenting patch submission

From: Jon Smirl (jonsmirl_at_yahoo.com)
Date: 05/27/04

  • Next message: Thomas Zehetbauer: "Re: CONFIG_IRQBALANCE for AMD64?" 
    Date:	Thu, 27 May 2004 12:13:05 -0400
To: linux-kernel@vger.kernel.org, lm@bitmover.com

    On Thu, 27 May 2004 07:51:27 -0700, Larry McVoy wrote:
    > 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.

    This is a classic case of wanting an audit trail just like you have in
    accounting packages. For audit trails you have to have the entire trail,
    not just pieces of it.

    I like the idea of nested packages signed by each person who touched it.
    The gives a perfect audit trail back to who authored each line. I'm sure
    bk could be modified to produce these automatically.

    I don't believe the size of this would get out of control. Only the master
    Linux repository has to keep all of it. bk clone could get a new option
    that says, i don't care about the downstream audit trail. Disks are cheap,
    I doubt if the entire Linux audit trail would fill up more than a couple
    of them.

    Audit trails are something that are rarely looked at but of vital
    importance. Linux needs complete and accurate audit trails. I agree that
    audit trails can clutter up patches, but the patches have to have these
    trails. The way to address this is via tools that convert the new patches
    into the old formats for people to read. Plus the bitkeeper interface
    would also hide all of the detail unless asked. Of course other source
    control systems will also need a set of helper tools too.

    Another problem is that you need a central key repository. Since it's
    pretty stupid to for each developer to send $2,000 to verisign for a key
    maybe bitmover would consider running the key repository. This is a
    painful job, if they want to do it, I'd let them.

    Jon Smirl, jonsmirl@yahoo.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: Thomas Zehetbauer: "Re: CONFIG_IRQBALANCE for AMD64?"

    Relevant Pages

    • Re: [RFD] Explicitly documenting patch submission
      ... because of how patches are fanned in through maintainers, ... pretend to have done so but we are not getting the authorship right. ... Solve that problem and you are lightyears closer to having an audit trail. ... the problem space is who wrote the patch, ...
      (Linux-Kernel)
    • 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: [RFD] Explicitly documenting patch submission
      ... > represents how the patch got into the tree. ... 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. ... I could build tools which record the secondary patches as diffs to ...
      (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)