I'd frame the reasoning differently: Our current merge strategy is
vestigial and we can't rely on it in many, if not most, cases. Patches
rarely merge cleanly across majors requiring -s ours w/amend or other
changes per branch. This effectively clutters up our git history, hides
multi-branch change
On Tue, Dec 7, 2021 at 8:18 AM Joshua McKenzie wrote:
> So let me pose the question here to the list: is there anyone who would
> like to advocate for the current merge strategy (apply to oldest LTS, merge
> up, often -s ours w/new patch applied + amend) instead of "apply to trunk
> and cherry-pic
>
> the need for some external pressure to maintain build quality, and the
> best solution proposed (to my mind) was the use of GitHub actions to
> integrate with various CI services to refuse PRs that do not have a clean
> test run
Honestly, I agree 100% with this. I took the more conservative ap
> My personal opinion is we'd be well served to do trunk-based development
with cherry-picks … to LTS release branches
Agreed.
> that's somewhat orthogonal … to the primary thing this discussion surfaced
> for me
The primary outcome of the discussion for me was the need for some external
press
>
> it would be far preferable for consistency of behaviour to rely on shared
> infrastructure if possible
>
For those of us using CircleCI, we can get a lot of the benefit by having a
script that rewrites and cleans up circle profiles based on use-case; it's
a shared / consistent environment and t
