Hi folks, Another thought on the topic is tooling support and tool integration: There is a hughe ecosystem around Github and very little around Phabricator. It took me 2 days to set up build jobs for the 10.x release branch [1]. There are nice build integrations for Github and it was smooth sailing. Setting up a build job for pull requests would just be a few clicks now. In contrast I've been spending weeks on setting up a proper integration of pre-merge tests [2] with Phabricator. And I'm far from having a proper solution and I know some corner cases we will never be able to solve properly with Phabricator. The root cause is: On Phabricator you review patches that might or might not be related to a git revision and the process for merging/landing might introduce even more changes. This is a fundamental problem with the data model and nothing that can be fixed easily. In Github pull requests there is always a git commit that you can just feed to the build server. And you can be sure of what really gets merged. You review, build and test exactly the change that gets merged afterwards. So from the build server perspective, Github is clearly the better solution. [1] https://buildkite.com/llvm-project/llvm-release-builds [2] https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md Best, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/8dbda8dd/attachment.html>
On Tue, Jan 21, 2020 at 1:45 AM Christian Kühnel via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi folks, > > Another thought on the topic is tooling support and tool integration: > There is a hughe ecosystem around Github and very little around > Phabricator. > > It took me 2 days to set up build jobs for the 10.x release branch [1]. > There are nice build integrations for Github and it was smooth sailing. > Setting up a build job for pull requests would just be a few clicks now. > > In contrast I've been spending weeks on setting up a proper integration of > pre-merge tests [2] with Phabricator. And I'm far from having a proper > solution and I know some corner cases we will never be able to solve > properly with Phabricator. The root cause is: On Phabricator you review > patches that might or might not be related to a git revision and the > process for merging/landing might introduce even more changes. This is a > fundamental problem with the data model and nothing that can be fixed > easily. > > In Github pull requests there is always a git commit that you can just > feed to the build server. And you can be sure of what really gets merged. > You review, build and test exactly the change that gets merged afterwards. >How would that be true? Given that upstream keep changing during the period of review? The commit is going to have to be rebased to head and that may involve making changes.> So from the build server perspective, Github is clearly the better > solution. > > [1] https://buildkite.com/llvm-project/llvm-release-builds > [2] > https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md > Best, > Christian > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/06c87d2d/attachment.html>
> > In Github pull requests there is always a git commit that you can just >> feed to the build server. And you can be sure of what really gets merged. >> You review, build and test exactly the change that gets merged afterwards. >> > > How would that be true? Given that upstream keep changing during the > period of review? The commit is going to have to be rebased to head and > that may involve making changes. >Yes, github tells you, that your PR has a merge conflict, that you need to resolve manually. Once you've pushed the conflict resolution to the same PR, it triggers another round of builds and tests. And also potentially another review, depending on what permissions you have and how the project ist set up... -- Best, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200122/8d8517db/attachment.html>