On Tue, Mar 19, 2019 at 2:00 PM Tom Stellard via cfe-dev < cfe-...@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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev