Date:	Sat, 22 Jan 2011 12:20:18 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Daniel Walker <dwalker@...eaurora.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Dima Zavin <dmitriyz@...gle.com>,
	Joe Perches <joe@...ches.com>, davidb@...eaurora.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/7] Nexus One Support

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists