On Thu, Apr 23, 2020 at 7:47 AM Florian Weimer <f...@deneb.enyo.de> wrote: > > * Tamar Christina: > > > A bit late to the party, but this really doesn't work that well > > because until recent version of gitlab there was no fairness > > guarantee. another patch could be approved after mine (with hours > > in between because of CI) and yet still get merged first causing my > > own patch to no longer apply, you'd rebase and roll the dice again. > > To fix this they added merge trains > > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ > > > > but trains for GCC Will likely be very short because of Changelog > > conflicts. So I don't think an automated merge workflow would work > > for projects where every single commit changes the same files. > > I had not thought about that. > > Does Gitlab support pluggable merge helpers? The gnulib changelog > auto-merger did a great job when we were still writing changelogs for > glibc.
Btw, I encourage everybody trying to experiment with CI to set it up for release branches first because of the lower check-in count. Richard.
