[development] Splitting up patches
nedjo at islandnet.com
Fri Aug 25 15:05:01 UTC 2006
> 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
(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
More information about the development