On Sat, Jan 22, 2011 at 01:18:54PM +0200, Pekka Enberg wrote: > Why is that? I don't see any technical problem of upstreaming the > original patches even if they don't compile (as long as they're not > included in Makefiles or Kconfig files). There's no need to hide the > real history even if it looks ugly... I've asked Daniel in private whether he'd mind posting the original set of patches which he based his work on to this thread. I suspect that the situation is that there's many patches which he's taken from the repository and consolidated them down into a nice set of easy to review patches. One of the problems of preserving the micro-detail of history right from the early inception of support for a platform is that quite often the early support is buggy or broken - it might not even compile. There may be 20 or so patches on top of that which eventually get it to a usable state. Do we really want to put off people from reviewing patches because of the size of micro-development that happened prior to getting to a point where the result of that development is usable? Tell me this: does a patch which cleanly adds support for board X get reviewed by more, the same, or less people than a set of twenty patches which goes about the same thing, adding code, removing previously added code, changing it again. I personally _hate_ patch sets which do that, and I tend to ignore them (or maybe review the first twenty patches before taking a break... and then never going back to them) because I quickly get tired reading all that code - which means I'm not able to do an effective review. I suspect most people suffer from reviewer tiredness when faced with large patch sets changing the same code time and time again. I personally believe that Daniel is doing the right thing here, except he needs to preserve a better record of authorship. I even think it's fine if he decides to drop people's sign-offs if he thinks the code has changed significantly from the original authors - provided he's willing to take responsibility for the submission of that code. If you read what a sign-off means (the DCO) then it's clear that if the code has changed significantly, the original sign-offs do not apply anymore - the original sign-offs can't warrant that the modified code is covered by appropriate licenses or even that the person who modified their code has the rights to submit it. Take a moment to think about that. If I took some of your code with your sign-off, changed it significantly by including someone elses work where there were no rights to submit that persons work into mainline, and I kept your sign-off on that, would you be happy when someone starts making accusations against you submitting their code? The sign-offs make no representation of who was the author. In many cases where companies are involved, the first sign-off is the person who authorized the release of the code, not the person who wrote the code, so it's a complete mistake to attribute authorship by whoever was listed first in the Sign-off lines. Authorship may be jointly held by the first 4 people listed, and attributing authorship to only the first is just as bad as not attributing authorship at all. Lastly, from the arguments being made over this, if they are supported, I think that people are saying that the actions listed in DCO (b) are no longer allowed, and so DCO (b) should be removed entirely as an acceptable practice. IOW, what's being promoted as "you must do" (iow, preserving all history) is completely contary to the allowances of DCO (b). -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
