[cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[Brian Cain via cfe-dev]

On Tue, Mar 19, 2019 at 2:00 PM Tom Stellard via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> I would like to follow up on the previous thread[1], where there was a
> consensus
> to disallow merge commits in the llvm github repository, and start a
> discussion
> about how we should enforce this policy.
>
> Unfortunately, GitHub does not provide a convenient way to fully enforce
> this policy.
> We can enforce it for pull requests, but not for direct pushes to the
> master branch,
> so we will have to come up with our own solution if we want to completely
> prevent
> merge commits.  I've spent some time looking into this and here are a few
> options that I've come up with (If you are a GitHub expert and have other
> suggestions, please let us know):
>
> 1. Have either a status check or use the "Rebase and Merge" policy for
> pull requests
> to disallow merge commits.  Disable direct pushes to the master branch and
> update the
> git-llvm script to create a pull request when a developer does `git llvm
> push` and
> then have it automatically merged if there are no merge commits.
>
> 2. Enforce no merge commits for pull requests, but sill allow developers
> to push directly
> to master without checking for merge requests.  This is essentially a best
> effort
> approach where we avoid having to implement our own custom work-flow for
> committing,
> while accepting the possibility that someone might accidentally push a
> merge commit.
>
> 3. Disable direct pushes to master, don't update the git-llvm script and
> require all
> developers to use pull requests, where this policy will be enforced.
>
> Which option do you prefer?
>
>
>
I don't think I have a preference regarding merge commits but having a
status check where some subset of build + test takes place is a really good
idea, IMO.  It would be great if it were applied for everyone but if that
causes too many problems, I would settle for opt-in.  Preferably not
all-or-nothing on the check.

Regarding the scope of the check (boldly assuming one would be in place):
the more, the better (so long as it's stable and tolerable to the team).
Some dev teams that use GH have a bot that optimistically batch
builds-and-tests commits and when failures inevitably happen, contributors
are encouraged to triage and re-enqueue their PR for being built if they
can surmise the failure is not due to their change.

When contributing changes upstream, it takes away some of the
stress/challenge if you have some independent automaton verify that your
change doesn't cause regressions.  As it stands I feel like I should be on
standby for 24 to 72 hours after the commit in order to investigate/revert
if my change causes someone problems.  I realize that it's prudent to limit
the scope such that the checks don't create an enormous backlog.


-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190320/6f5f6fe2/attachment.html>