Messages in this thread | | | Date | Tue, 25 May 2004 13:08:34 -0500 | From | Andy Isaacson <> | Subject | Re: [RFD] Explicitly documenting patch submission |
| |
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 - 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/
| |