Re: [Xen-devel] [RFC v2 0/9] error: auto propagated local_err

[Vladimir Sementsov-Ogievskiy <vsementsov@xxxxxxxxxxxxx>]

24.09.2019 18:28, Eric Blake wrote:
> On 9/24/19 9:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> 
>>>> 3. What to do with huge auto-generated commit 07? Should I split it
>>>> per-maintainer or per-subsystem, or leave it as-is?
>>>
>>> It's big. I'd split it into multiple patches (and reduce the cc - except
>>> for the cover letter, the rest of the patches can be limited to the
>>> actual maintainer/subsystem affected rather than everyone involved
>>> anywhere else in the series. With the current large cc, anyone that
>>> replies gets several mail bounces about "too many recipients").  It may
>>> be easier to split along directory boundaries than by maintainer
>>> boundaries.  Markus has applied large tree-wide Coccinelle cleanups
>>> before, maybe he has some advice.
>>
>>
>> If split by subsystem it would be 200+ patches:
>> git diff --name-only | while read f; do scripts/get_maintainer.pl -f $f 
>> --subsystem --no-rolestats 2>/dev/null | grep -v @ | head -1; done | sort | 
>> uniq | wc -l
>> 205
>>
>>
>> Try to look at larger subsystem:
>> git diff --name-only | while read f; do scripts/get_maintainer.pl -f $f 
>> --subsystem --no-rolestats 2>/dev/null | grep -v @ | tail -2 | head -1; done 
>> | sort | uniq | wc -l
>> 139
>>
>> still too many.. Or is it OK?
> 
> Hmm - that becomes a tradeoff in length of the series (where individual
> patches may be reviewed fast, but where the overall process may be
> bogged down by sheer length), vs. length of individual emails (where the
> email itself is daunting, but as the review is mechanical and done by
> automation, it becomes a matter of spot-checking if we trust that the
> automation was done correctly).  You can probably group it in fewer
> patches, by joining smaller patches across a couple of subsystems.  It's
> an art form, there's probably several ways to do it that would work, and
> it comes down to a judgment call on how much work you want to do to try
> and reduce other's work in reviewing it.  Maybe even an off-hand split
> of gathering files until you reach about 500 or so lines per diff.  I
> wish I had easier advice on how to tackle this sort of project in the
> way that will get the fastest response time.
> 
> 
>>>>    vl.c                                          |  13 +-
>>>>    scripts/coccinelle/auto-propagated-errp.cocci |  82 +++++++
>>>>    319 files changed, 2729 insertions(+), 4245 deletions(-)
>>>>    create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
>>>
>>> The diffstat is huge, but promising.
> 
> We also learned in reviews of 7/9 that the diffstat here is misleading,
> the number of insertions will definitely be increasing once the
> Coccinelle script is fixed to insert the macro in more functions, but
> hopefully it's still a net reduction in overall lines.
> 

No hope for us: with fixed script I now see

919 files changed, 6425 insertions(+), 4234 deletions(-)

-- 
Best regards,
Vladimir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel