Re: [RFD] Explicitly documenting patch submission

[Jon Smirl]

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@xxxxxxxxx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/