Re: PATCH: remove runtest_start procedure

[Jacob Bachmeyer]

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