This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc][00/37] Eliminate builtin_type_ macros
- From: David Miller <davem at davemloft dot net>
- To: mark dot kettenis at xs4all dot nl
- Cc: uweigand at de dot ibm dot com, gdb-patches at sourceware dot org
- Date: Sun, 31 Aug 2008 20:45:17 -0700 (PDT)
- Subject: Re: [rfc][00/37] Eliminate builtin_type_ macros
- References: <20080831175045.128504000@de.ibm.com> <200808312218.m7VMIGPq030239@brahms.sibelius.xs4all.nl>
From: Mark Kettenis <mark.kettenis@xs4all.nl>
Date: Mon, 1 Sep 2008 00:18:16 +0200 (CEST)
> I've probably had one piwo too many at this point, but can we please
> stop this Linux [x/zillion] crap? You can't seriously pretend there
> are really 37 independent diffs that people would want to review
> and/or test can you?
Why is it crap to split up a large harder to review (and bisect)
change into bite size (easier to review and later bisect) independant
pieces? And why is it purely labelled as "a Linux thing" to split up
a large patch this way? I've seen this submission technique used in
many other projects.
If a reviewer doesn't have time to review the whole bit, they can
choose to look at one a few or even just one of them, when it is
split up like this.
What if later there is a regression and someone tries to bisect
through this change? If we have just one huge one it's harder to
figure out which of the 37 parts caused the problem, whereas if
we could bisect to one of these 37 pieces, we'd know precisely which
part added the regression.
That is just smart development as far as I can see.
The response I am seeing seems like a negative knee jerk reaction to
me. I post sets of 50 patches at a time frequently for some of my
work, and it eases the reviewer burdon tremendously.