From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dima Zavin Subject: Re: [PATCH 0/7] Nexus One Support Date: Sat, 22 Jan 2011 10:06:44 -0800 Message-ID: References: <20110121094827.41818a55@jbarnes-desktop> <20110121095658.1ab623fe@jbarnes-desktop> <1295632828.19880.22.camel@m0nster> <20110121100441.06a94482@jbarnes-desktop> <1295633882.19880.31.camel@m0nster> <1295642995.19880.42.camel@m0nster> <1295643762.25868.31.camel@Joe-Laptop> <1295645098.22882.1.camel@m0nster> <20110122122018.GC5194@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from smtp-out.google.com ([216.239.44.51]:54659 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387Ab1AVSGs convert rfc822-to-8bit (ORCPT ); Sat, 22 Jan 2011 13:06:48 -0500 Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p0MI6kx8016890 for ; Sat, 22 Jan 2011 10:06:46 -0800 Received: from qwk3 (qwk3.prod.google.com [10.241.195.131]) by kpbe16.cbf.corp.google.com with ESMTP id p0MI6iFm007414 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 22 Jan 2011 10:06:45 -0800 Received: by qwk3 with SMTP id 3so2690173qwk.30 for ; Sat, 22 Jan 2011 10:06:44 -0800 (PST) In-Reply-To: <20110122122018.GC5194@n2100.arm.linux.org.uk> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Russell King - ARM Linux Cc: Pekka Enberg , Daniel Walker , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Jesse Barnes , Joe Perches , davidb@codeaurora.org, linux-arm-kernel@lists.infradead.org Russell, I completely agree with you that the entire history of the evolution of the code is not interesting or useful to everyone on the list or in linux kernel tree. I'm not advocating posting the original patches (which as you rightfully point out are plentiful due to long development cycle). It would be a waste of time. I also like how Daniel has split up the board file additions into nice small patches, and I already thanked him for doing this work. All I ask is that if files are directly copied out of the tree with only slight modifications or if they are copied and stripped down for easier consumption, just say Original Authors: if it's reasonable to gather who the primary contributors are. If that is hard due to lots of commits and squashes, even a Cc: to the people who wrote the code would have been enough. Had any of that been done, I would have not said a word. I still do appreciate Daniel's efforts and the way he is splitting up the commits for public consumption, as they do logically make sense. --Dima On Sat, Jan 22, 2011 at 4:20 AM, Russell King - ARM Linux wrote: > 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 ofte= n > the early support is buggy or broken - it might not even compile. =A0= 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 poi= nt > 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 patch= es > which goes about the same thing, adding code, removing previously add= ed > code, changing it again. > > I personally _hate_ patch sets which do that, and I tend to ignore th= em > (or maybe review the first twenty patches before taking a break... an= d > then never going back to them) because I quickly get tired reading al= l > that code - which means I'm not able to do an effective review. =A0I > suspect most people suffer from reviewer tiredness when faced with la= rge > patch sets changing the same code time and time again. > > I personally believe that Daniel is doing the right thing here, excep= t > he needs to preserve a better record of authorship. =A0I even think i= t's > fine if he decides to drop people's sign-offs if he thinks the code h= as > changed significantly from the original authors - provided he's willi= ng > 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 t= he > 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 modifi= ed > their code has the rights to submit it. > > Take a moment to think about that. =A0If I took some of your code wit= h > your sign-off, changed it significantly by including someone elses wo= rk > 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 sta= rts > making accusations against you submitting their code? > > The sign-offs make no representation of who was the author. =A0In man= y > 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 w= as > listed first in the Sign-off lines. =A0Authorship may be jointly held= by > the first 4 people listed, and attributing authorship to only the fir= st > is just as bad as not attributing authorship at all. > > Lastly, from the arguments being made over this, if they are supporte= d, > 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. =A0IOW, 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html