Re: [PATCH 00/03] gpio: Renesas R-Car GPIO driver update

[Linus Walleij]

On Tue, Mar 19, 2013 at 4:36 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
> On Thu, Mar 14, 2013 at 10:13 PM, Laurent Pinchart
> <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:

>> When submitting new drivers I usually try not to make the development history
>> visible to mainline. It brings little additional value (beside possibly making
>> backporting a bit easier, but in the devm_* case that shouldn't be a problem,
>> unless Simon thinks otherwise) but adds review complexity, as reviewers need
>> to validate the intermediate versions as well. More patches also mean more
>> potential bisection breakages.
>
> Huh, it seems that my point of view is the total opposite. I see that
> using incremental patches to show new development would make review
> _easier_. Perhaps that's not the case for most people.

As subsystem maintainer what I don't want to see is a patch that
at one point breaks something in some configuration and then later
fixes it. Then I strongly prefer squashing. (Greg also mentions this
in one of his seminars.)

What really makes me mad is the the above pattern + claim that
it must be done in that way to preserve authorship. Like legaleaze
or credit is more important that functionality.

If all patches are bisectable and perfectly fine then whether you
take 8 stops when driving to Rome or just drive there in one
big stretch is more a technical, secondary thing. Do whatever you
like as long as all commits build and boot.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/