Re: [RFD] Explicitly documenting patch submission

["J. Bruce Fields" <bfields@fieldses.org>]

On Sat, May 22, 2004 at 11:46:29PM -0700, Linus Torvalds wrote:
> This is not about proving authorship - it's about documenting the
> process. This does not replace or preclude things like PGP-signed
> emails, this is _documenting_ how we work, so that we can show people
> who don't understand the open source process.

What aspects of the process do you want to document?

The patch-submission process can be more complicated than a simple path
up a heirarchy of maintainers--patches get bounced around a lot
sometimes.

If you're trying to document who contributes "intellectual property" to
the kernel, then documenting the process of creating the patch would
seem more important than documenting the actual submission--any
significant change is often the result of complicated discussions
between multiple parties who wouldn't necessarily appear in the chain of
submittors.

I gues I'm still a little vague as to exactly what sort of questions we
expect to be able to answer using this new documentation.

A couple examples (which I think aren't too farfetched):
	* Developer A submits a patch which is dropped by maintainer B.
	  I later notice this and resubmit A's patch to B.  I don't
	  change the patch at all, and the resubmission is my only
	  contribution to the process.  Do I need to tag on my own
	  "Signed-off-by" line?
	* 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?

--Bruce Fields