> 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. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
