Could margebot squash?

[Richard Eisenberg]

Both the current workflow and the one Joachim proposes here make sense to me, with different pros and cons. But I think now is not the time for this debate: what we have currently isn't working well enough to consider design changes. That is, CI frequently has spurious failures, and it remains (for me, at least) mostly a hope that margebot works when assigned. (There are various conditions that stop margebot from working, though without reporting any error messages.) My understanding is that we were trying to get sufficient support within GitLab so that merge trains didn't rely on margebot. I thus think that CI reliability and maintainability should be our focus in this area; reorienting to a new design would, I fear, distract our limited energy away from that focus.

Richard

> On Apr 2, 2022, at 7:28 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> as far as I understand, the expected workflow for MRs is that when they
> are ready, the developer manually squashes the chronological commit
> history of the MR into a logical one with polished commit messages,
> typically consisting of a single commit, but could be multiple ones,
> and then assigns the MR to margebot, which will rebase that sequence of
> commits onto the staging branch and eventually merges that into master.
> 
> One downside of this approach is that it requires destructive changes
> to work-in-progres branches: I might think the MR is ready, squash the
> commit sequence into a single commit, but then more work is ready. Now
> it’s hard to revert individual patches, or collaborate with others,
> because the git history was disrupted.
> 
> Another is that the commit message itself isn’t very easily visible to
> reviewers.
> 
> In other similarly sized projects (e.g. mathlib) I often see a mode
> where the actual commits of the MR are ignored (so they can represent
> the true git history of the branch, including merges and all that grit,
> which is good for collaboration and for reviewers to understand what
> has happened, without requiring developers to spend cosmetics effort on
> them), and upon merging by margebot/bors/mergify/whatever, the MR is
> merged as a single commit with the description taken from the MR
> description (which encourages developers to keep the MR description up
> to date as the MR develops, reviewers can easily see that).
> 
> A downside of this that you’ll always get one commit on master per MR.
> If you like to submit a curated list of logical commits within one MR,
> then this would not work, and you’d have to use multiple MRs.
> 
> 
> Has this been considered?
> 
> (I don’t want to cause unnecessary disruption with a presumptious call
> for action here; take it as a comment to weigh in in if and when this
> part of our infrastructure is about to change anyways, or maybe a
> careful probe if my sentiment may be shared widely.)
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs