Re: Not usable email content encoding

[Jeff Law <law@redhat.com>]

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