[Gluster-devel] Splitting patches, was Re: Ability to skip regression jobs?

[Jeff Darcy]

> One way to reduce load is to figure out a way to award +1s to parent
> patches when a dependent patch passes regression. It is recommended
> that a change be split into as many smaller sets as possible.
> Currently, if we send 4 patches that need to be serially merged, all 4
> have to pass regressions. Instead, if Jenkins offered a way to block
> merging of subset of patches and made it possible to take all 4 in in
> one go, we could run tests only on top of these patches. The last time
> I checked, such a feature did not exist in Jenkins.

Yes, this is my biggest problem with git/Gerrit/Jenkins.  If one has
many related changes (as e.g. for multiplexing), the "advice" to break
it into smaller pieces *does not work*.  At best, all of the pieces have
to be run through our entire heavyweight process in order, taking
forever.  More likely, they'll be merged out of order so dependencies
must be carefully tracked and local trees rearranged.  I already have to
budget half an hour just to get things into a buildable and testable
state every time I come back to multiplexing after working on something
else.  As a stack of separate patches it would take three times as long.
If a group of related changes could be reviewed separately (often by
different groups of people) but tested and merged together, that would
be great, but neither our tools nor our homegrown bits seem very
amenable to that.