![]() | |||||||||||||
Messages in this thread |
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. > If you're trying to document who contributes "intellectual property" to > the kernel No, that's not what it is either. At least to me, equally important as the actual author is how it got reviewed, and what path it took. Because when problems happen (say a simple bug), I want the whole path to know. Think of it this way (purely technical to avoid any emotional arguments): we've hunted down a change that results in strange behaviour, and what we want to do is get the problem explained and resolved. Maybe the thing to do is to just revert the whole change, but usually we just want to fix it, and regardless of whether we want to undo it or fix it, what we want to do is get the people who were involved with not just writing the code, but approving it too to look at the issue. And the people who approved it literally _are_ as important as the people who wrote it (forget any copyright issues), since (a) they need to know to avoid the problem in the first place and (b) they usually know why the code was added and what problems _they_ saw (or didn't see) when they approved it. See? That's why to me, the set of people who have been involved in the whole patch "lifetime" is actually _more_ important than the original author. The original author is obviously special in some respects, but from a problem solving perspective he's not necessarily even the person to go to. > 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. See above. I explicitly picked a _technical_ reason for tracking who has been involved with a patch, but let's say that somebody raises concerns over any _other_ issues about the code - the fact is that the same logic applies. The original author is a bit special, but the path it took is still equally important. > 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? Yup. And part of it is simply credit: trust me when I say to you that "maintenance" of patches is a job that it at _least_ as important as writing them in most cases. That's not always true, of course - there are pieces of code that are just stunning works of art, and very important, and as programmers we like to think of those really fundamental contributions. But in real life, it's definitely the old case of "1% inspiration, 99% persiration", and we should just accept that. For example, look at the kernel developers out there, and ask yourself who stands out. There's a couple of great coders, but I think the people who really stand out are people like Andrew, who mostly really "organize" and act as managers. Right? So when you save a patch from oblivion by passing it on to the right person, and get it submitted when it was originally dropped by some reason, you're actually doing a fundamentally important job. Maybe it's just one small piece of the puzzle, but hey, you'd only get one small line in the changeset, so the credit (or blame ;) really is appropriate. > * 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? Linus - 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/ | ||||||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||