On Tue, Mar 19, 2013 at 4:36 AM, Magnus Damm <[email protected]> wrote: > On Thu, Mar 14, 2013 at 10:13 PM, Laurent Pinchart > <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
