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. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org