lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 27 Mar 2013 13:34:23 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org,
	grant.likely@...retlab.ca, horms@...ge.net.au
Subject: Re: [PATCH 00/03] gpio: Renesas R-Car GPIO driver update

On Tue, Mar 19, 2013 at 4:36 AM, Magnus Damm <magnus.damm@...il.com> wrote:
> On Thu, Mar 14, 2013 at 10:13 PM, Laurent Pinchart
> <laurent.pinchart@...asonboard.com> 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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ