[tz] [PROPOSED PATCH 3/3] zic: check more consistently for I/O errors and improve diagnostics

Dirkjan Ochtman dirkjan at ochtman.nl
Tue Aug 19 08:58:48 UTC 2014

On Tue, Aug 19, 2014 at 10:52 AM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> That's debatable.  Given a set of closely related patches, I often find it
> more efficient to review them all at one go rather than one at a time.  In
> this case it also happened to be easier for me to generate and perhaps I'm
> biased by that, but there it is.

I understand that they're easier to generate; I often generate mine in
one go, and then split them out with git add -i.

> More generally, I would rather avoid the bureaucratic overhead of splitting
> patches unless there's a significant win in doing so.  Many patches that I
> write could technically be split into dozens of niggling little independent
> changes, but the overall utility of doing it that way would be negative --
> certainly for me, and I expect even when reviewer labor is taken into
> account.

I've always found that review time on single-purpose refactoring
patches is exponentially less than the review time on the combined
patch, and I also don't see much overhead in doing it that way. But I
guess it depends on what tools you use.



More information about the tz mailing list