I think we definitely will want to support github PRs, at the very least as an _option_, even if we continue running/preferring phabricator.
Github PRs are how everyone who is not already super-involved in the llvm project is going to want to contribute changes, and we ought to be as welcoming as possible to such users. On Tue, Mar 19, 2019 at 3:15 PM Roman Lebedev via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Tue, Mar 19, 2019 at 10: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? > All these options include at least partial usage of/switch to github pr's. > I don't think that was discussed before. (FWIW i'm opposed to that.) > > Is there a fourth option - ask github whether they could make an exception > for LLVM to use server-side hooks? They are available in github enterprise. > > > -Tom > Roman. > > > [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html > > _______________________________________________ > > cfe-dev mailing list > > cfe-...@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > _______________________________________________ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
