[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: remove runtest_start procedure

From: Jacob Bachmeyer
Subject: Re: PATCH: remove runtest_start procedure
Date: Sat, 15 Dec 2018 01:42:22 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

Ben Elliston wrote:
On Thu, Dec 13, 2018 at 11:32:59PM -0600, Jacob Bachmeyer wrote:
The ChangeLog entry lists some other minor changes also included.
Thanks. This is great.

Can I ask, though, that minor cleanups be sent as a separate patch to
more significant patches? It makes reviewing the more complex changes
easier. Thanks.

Having looked at that patch again, I see two possible sub-patches: one for functional changes and one for tidying the code. I will make an effort to separate these in the future, although this pair of patches (this one and its predecessor) were themselves split intending to ease review, albeit by a fuzzy heuristic: is this logically a complete change? If yes, send a patch and then work on the next changes.

Is it better to write new code close to the existing style and then patch both for cleanup or to write new code in "new" style and patch only the old code in cleanup? Should such patch groups be sent in one email or split "[PATCH n/m]" style as is done on LKML? (Although as I understand the type of cleanup we are doing is very rare there -- C has not changed much, while Tcl has. For example, bracing "if" expressions is now recommended, but I suspect that the syntax now recommended was forbidden in some archaic Tcl version -- that was probably current when DejaGnu was written.)

I suppose the real question is: what are the trade-offs to minimize the overall effort required for review? Is there significant per-patch overhead (pushing to group patches: 10+1 + 10+1 + 10+1 + 10+1 == 44 but 10+4 == 14), is the review effort more proportionate to total diff size (neutral impact), or is the effort to review greater than linear in diff size for each patch (pushing to split patches: 1^2 + 1^2 + 1^2 + 1^2 == 4 but 4^2 == 16)?

In sending patches, nearly all of the effort is (relatively) fixed overhead per-patch -- extracting diffs from Git is point-and-click and the rest is select-and-paste, with a bit of whitespace-cleanup editing in the middle. Most of the "work" is filling out the "compose email" window. :-)

-- Jacob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]