Re: [RFD] Explicitly documenting patch submission

[Larry McVoy]

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.

Solve that problem and you are lightyears closer to having an audit trail.
You currently aren't recording the original author and you are trying
to record all the people who touched the patch along the way.  If you
can't get the easy part right what makes you think you are going to get
the hard part right?

Before the obligatory BK flames start up, note this is a problem that
you would have with any SCM system.  The problem has nothing to do with
which SCM system you use, it has to do with recording authorship.

I think it's great that you are looking for a better audit trail but
I think it is strange that you are trying to get a perfect audit trail
when you don't even have the basics in place.  What was it that you said,
"Perfect is the enemy of good", right?  In my opinion the 99% part of
the problem space is who wrote the patch, not who passed it on.  If, and
that's a big if, you get to the point where you have proper authorship
recorded and then you still want to record the path it took, that's a
different matter.  The way you are going about it I think you may end
up with nothing by trying to be so perfect.  If I'm wrong, what's wrong
with fixing things so that you get the authorship right and then extend
to get the full path right?

This leaves aside the issue that patches can get applied multiple times
(and do all the time, I think we've counted thousands or tens of thousands
of this in the kernel history).

For what it is worth, we've actually thought through what you are trying
to do long ago and calculated the amount of metadata you'd end up carrying
around and found it to be way way way way too large for an SCM system to
justify.  It's unlikely we'd ever want full audit trails in BK because
patches tend to flow through multiple trees and get merged with other 
patches, etc.  The thing we found useful was who wrote the patch and in
what context.

We did change BK a few revs back to record both the importer and the
patch author when people use your import scripts (bk import -temail)
so we have a 2 deep audit trail already.  More than that seems like
overkill.

The more I think about it the more I wonder what problem it is you are 
trying to solve with the A->B->C->D->Linus audit trail.  Legally, the
issue is going to be with A more than anyone else.  What am I missing?
-- 
---
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/