[lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy
Brian Cain via lldb-dev
lldb-dev at lists.llvm.org
Wed Mar 20 19:38:26 PDT 2019
On Tue, Mar 19, 2019 at 2:00 PM Tom Stellard via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> I would like to follow up on the previous thread, where there was a
> to disallow merge commits in the llvm github repository, and start a
> 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
> 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
> approach where we avoid having to implement our own custom work-flow for
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev