>> That's funny - on one hand I'm asked to not submit huge patches (not
by
>> you, but by others), but on the other hand not having the consuming
code
>> in the same patch as the providing one is now deemed to be a
problem.
>
>Nope.
>
>Each patch should do a single logical thing. That doesn't mean that
we
>want to trickle patches in across a period of months. It means that
a
>bunch of spearate (and separately reviewed) patches can all go in at
the
>same time.
>
>So the split-it-up request is for reviewing (and debugging)
convenience
>only.
Forgive my non-understanding:
First, I rarely saw any kind of positive review feedback from lkml
besides the notification that you added something to your -mm tree
(negative things of course always arrive), yet no feedback at all is far
from meaning that a given patch is ever going to be accepted (as a
really good example take the tiny patch to fix the broken range check in
i386's low level NMI handler).
Second, since patches depend on one another in many cases it seemed
most natural to me to first break out things that aren't directly
related to nlkd or, if directly related, could still be viewed as
independent pieces of work. Hence I wouldn't consider it reasonable to
break up the debugger patch entirely and submit all the pieces at once,
because that could easily mean that if one intermediate piece doesn't
get accepted all the dependent pieces have been separated out
pointlessly.
I'd be curious to know how you, considering yourself in my position,
would have approached breaking up and submitting that size a patch.
Thanks,
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |