On Thu, 2020-04-23 at 09:34 +0100, Jonathan Wakely via Gcc wrote: > On Thu, 23 Apr 2020 at 06:49, Florian Weimer 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. > > I've been having problems with it recently, e.g. > https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog, > because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog > entry in the wrong place in gcc/testsuite/Changelog, as a result of a > rebase using merge-changelog. > > Maybe we should follow glibc and get rid of ChangeLog files before > trying to use automated CI and Git workflows. This is precisely why I want to get rid of ChangeLogs and instead generate them from the VCS as part of the release process. Ultimately I want to be able to use workflows where I can push a button on something that's gone through a CI cycle or "git am" and not have to go back and fix things *by hand*.
What we do with ChangeLogs is (*&@#$*)(*&^ insane from an efficient workflow standpoint. jeff
