[development] Splitting up patches

[Nedjo Rogers]

> I think a sensible rule of thumb would be "split up patches where you 
> can," for the reasons you specify. But there are some places where it 
> either just doesn't make sense, or worse makes things more difficult,  and 
> it would be great if core committers could keep that in mind when  making 
> these requests.

I see a tension between two principles: (1) we break up patches, and (2) 
each patch must be mature and complete before it's applied. These come into 
conflict when we have a large problem that needs a large solution. Yes, we 
can break the problem up, but each piece (patch) necessarily will be 
incomplete and immature until they're all done.

Maybe to successfully break up large improvements we need an approach 
something like:
(a) Signoff in principle in advance from a core committer: no guarantees, 
but the proposal seems the right general direction. And commitment from the 
group leading the change: we will follow through on cleanup after the 
patches go in.
(b) Direction and agreement to break particular pieces off.
(c) A relaxed readiness criterion for the pieces (individual patches) as 
they're applied. These are steps toward a goal.
(d) Completion patches at the end to integrate the pieces.

And I agree with both Neil and Angie. Some things are cleaner split off. And 
some things are so integral that they need at least a core that's large, 
though beyond that, sure, details can be hived off to be done 
separately/later.