Re: [RFD] Explicitly documenting patch submission

[Andy Isaacson <adi@hexapodia.org>]

On Tue, May 25, 2004 at 10:05:26AM -0700, Linus Torvalds wrote:
> On Tue, 25 May 2004, J. Bruce Fields wrote:
> > The patch-submission process can be more complicated than a simple path
> > up a heirarchy of maintainers--patches get bounced around a lot
> > sometimes.
> 
> Yes. And documenting the complex relationships obviously can't be sanely 
> done. The best we can do is a "it went through these people".
> 
> Perfect is the enemy of good. If we tried to be perfect, we'd never get 
> anything done.

Agreed, but...

> > 	* I write a patch.  Developers X and Y suggest significant
> > 	  changes.  I make the changes before I submit them to maintainer
> > 	  Z.  Suppose the changes are significant enough that I no longer
> > 	  feel comfortable representing myself as the sole author of the
> > 	  patch.  Should I also be asking developer X  and Y to add their
> > 	  own "Signed-off-by" lines?
> 
> That, my friend, is a matter of your own taste and conscience. My answer
> is that if you wrote it all, you clearly don't _need_ to. At the same
> time, I think that it's certainly in good taste to at least _ask_ them. 
> Wouldn't you agree?

This is one example of a general class of problem; another example is
"Andrew integrated 15 patches into -mm5".  When you have an aggregate
work representing a conglomeration of works from several different
developers, it becomes unwieldy to apply "tags" as you're suggesting.

What if I send a patch to l-k, and Bruce forwards it on to Andrew;
meanwhile, Joe sends another patch to l-k and Peter forwards it on to
Andrew.  Andrew integrates both patches, as well as several unrelated
bits he creates himself, into -mm77, which he sends to Linus and gets
integrated.

My signature can only apply to the patch I submitted, but that
distinction has been demolished long before the patch got anywhere near
a database that might be able to record it.  If we get lucky, the patch
in the l-k archives might be recognizable in -mm77.patch and the
resultant cset.

This problem is somewhat mitigated if all "aggregators" use BK, since
BKs csets preserve the boundaries of attestation that are interesting
here.  But it's not reasonable or sane to try to filter this problem
through BK.

-andy