From ben at well-typed.com Tue Oct 30 04:54:42 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Oct 2018 00:54:42 -0400 Subject: [GHC DevOps Group] The future of Phabricator Message-ID: <87zhuw2fw2.fsf@smart-cactus.org> TL;DR. For several reasons I think we should consider alternatives to Phabricator. My view is that GitLab seems like the best option. Hello everyone, Over the past year I have been growing increasingly weary of our continued dependence on Phabricator. Without a doubt, its code review interface is the best I have used. However, for a myriad of reasons I am recently questioning whether it is still the best tool for GHC's needs. # The problem There are a number of reasons why I am currently uncertain about Phabricator. For one, at this point we have no options for support in the event that something goes wrong as the company responsible for Phabricator, Phacility, has closed their support channels to non-paying customers. Furthermore, in the past year or two Phacility has been placing their development resources in the parts their customers pay them for, which appear to be much different that the parts that we actively use. For this reason, some parts that we rely on seem oddly half-finished. This concern was recently underscored by some rather unfortunate misfeatures in Harbormaster which resulted in broken CI after the Hadrian merge and now apparent bugs which have made it difficult to migrate to the CircleCI integration we previously prepared. Perhaps most importantly, in our recent development priorities survey our use of Phabricator was the most common complaint by a fair margin, both in case of respondents who have contributed patches and those who have not. On the whole, past contributors and potential future contributors alike have strongly indicated that they want a more Git-like experience. Of course, this wasn't terribly surprising; this is just the most recent case where contributors have made this preference known. Frankly, in a sense it is hard to blame them. The fact that users need to install a PHP tool, Arcanist, to contribute anything but documentation patches has always seemed like unnecessary friction to me and I would be quite happy to be rid of it. Indeed we have had a quite healthy number of GitHub documentation patches since we started accepting them. This makes me thing that there may indeed be potential contributoes that we are leaving on the table. # What to do With Rackspace support ending at the end of year, now may be a good time to consider whether we really want to continue on this road. Phabricator is great at code review but I am less and less certain that it is worth the maintenance uncertainty and potential lost contributors that it costs. Moreover, good alternatives seem closer at-hand than they were when we deployed Phabricator. ## Move to GitHub When people complain about our infrastructure, they often use GitHub as the example of what they would like to see. However, realistically I have a hard time seeing GitHub as a viable option. Its feature set is simply insufficient enough to handle the needs of a larger project like GHC without significant external tooling (as seen in the case of Rust-lang). The concrete reasons have been well-documented in previous discussions but, to summarize, * its review functionality is extremely painful to use with larger patches * rebased patches lead to extreme confusion and lost review comments * it lacks support for pre-receive hooks, which serve as a last line of defense to prevent unintended submodule changes * its inability to deal with external tickets is problematic * there is essentially no possibility that we could eventually migrate GHC's tickets to GitHub's ticket tracker without considerable data loss (much less manage the ticket load that would result), meaning that we would forever be stuck with maintaining Trac. * on a personal note, its search functionality has often left me empty-handed On the whole, these issues seem pretty hard to surmount. ## Move to GitLab In using GitLab for another project over the past months I have been positively surprised by its quality. It handles rebased merge requests far better than GitHub, has functional search, and quite a usable review interface. Furthermore, upstream has been extremely responsive to suggestions for improvement [1]. Even out-of-the-box it seems to be flexible enough to accommodate our needs, supporting integration with external issue trackers, having reasonable release management features, and support for code owners to automate review triaging (replacing much of the functionality of Phabricator's Herald). Finally, other FOSS projects' [3] recent migrations from Phabrictor to GitLab have shown that GitLab-the-company is quite willing to offer help when needed. I took some time this weekend to try setting up a quick GHC instance [2] to play around with. Even after just a few hours of playing around I think the result is surprisingly usable. Out of curiosity I also played around with importing some tickets from Trac (building on Matt Pickering's Trac-to-Maniphest migration tool). With relatively little effort I was even able to get nearly all of our tickets (as of 9 months ago) imported while preserving ticket numbers (although there are naturally a few wrinkles that would need to be worked out). Naturally, I think we should treat the question of ticket tracker migration as an orthogonal one to code review, but it is good to know that this is possible. ## Continue with Phabricator Continuing with Phabricator is of course an option. Its review functionality is great and it has served us reasonably well. However, compared to GitLab and even GitHub of today its features seem less distinguished than they once did. Moreover, the prospect of having to maintain a largely stagnant product with no support strikes me as a slightly dangerous game to play. Working around the issues we have recently encountered has already cost a non-negligible amount of time. # The bottom line If it wasn't clear already, I think that we should strongly consider a move to GitLab. At this point it seems clear that it isn't going to vanish, has a steady pace of development, is featureful, and available. However, these are just my thoughts. What do you think? Cheers, - Ben [1] 11.4 will ship with a file tree view in the code review interface, which I reported (https://gitlab.com/gitlab-org/gitlab-ce/issues/46474) as being is one of the Phabricator features I missed the most during review [2] https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641 [3] The GNOME and freedesktop.org projects have recently migrated, the former from a hodge-podge of self-hosted services and the latter from Phabricator -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From marlowsd at gmail.com Tue Oct 30 08:54:44 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 30 Oct 2018 08:54:44 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87zhuw2fw2.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: Just on this particular point, and narrowing to ghc-devops only: On Tue, 30 Oct 2018 at 04:54, Ben Gamari wrote: > > For one, at this point we have no options for support in the event that > something goes wrong as the company responsible for Phabricator, > Phacility, has closed their support channels to non-paying customers. > Furthermore, in the past year or two Phacility has been placing their > development resources in the parts their customers pay them for, which > appear to be much different that the parts that we actively use. For > this reason, some parts that we rely on seem oddly half-finished. > Part of the point of the ghc-devops group was that we could pool funds to pay for infrastructure. So this doesn't seem like a blocker - in practical terms would we be able to get the support we need from Phacility for a reasonble amount? (I realise it's by no means the only problem that you raised in your message though, I'll also respond on the main thread) Cheers Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Oct 30 09:07:54 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 30 Oct 2018 09:07:54 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87zhuw2fw2.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: I'm entirely happy to move, provided (1) whatever we move to provides the functionality we need, and (2) it's clearly what the community wants (considering both current and future contributors). In the past when moving to GitHub was brought up, there were a handful of core contributors who argued strongly in favour of Phabricator, do we think that's changed? Do we have any indication of whether the survey respondents who were anti-Phabricator would be pro- or anti-GitLab? Personally I'd like to optimise for more code review, because I think that more than anything else will increase quality and community ownership of the project. If using new tooling will make code review a more central part of our workflow, then that would be a good thing. Right now I think we're very Trac-centric, and the integration between Trac and Phabricator isn't great; if we could move to a solution with tighter integration between tickets/code-review/wiki, that would be an improvement in my view. But not GitHub, for the reasons you gave. Would GitLab solve the CI issues? I don't think you mentioned that explicitly. Cheers Simon On Tue, 30 Oct 2018 at 04:54, Ben Gamari wrote: > > TL;DR. For several reasons I think we should consider alternatives to > Phabricator. My view is that GitLab seems like the best option. > > > Hello everyone, > > Over the past year I have been growing increasingly weary of our > continued dependence on Phabricator. Without a doubt, its code review > interface is the best I have used. However, for a myriad of reasons I > am recently questioning whether it is still the best tool for GHC's > needs. > > > # The problem > > There are a number of reasons why I am currently uncertain about > Phabricator. > > For one, at this point we have no options for support in the event that > something goes wrong as the company responsible for Phabricator, > Phacility, has closed their support channels to non-paying customers. > Furthermore, in the past year or two Phacility has been placing their > development resources in the parts their customers pay them for, which > appear to be much different that the parts that we actively use. For > this reason, some parts that we rely on seem oddly half-finished. > > This concern was recently underscored by some rather unfortunate > misfeatures in Harbormaster which resulted in broken CI after the > Hadrian merge and now apparent bugs which have made it difficult to > migrate to the CircleCI integration we previously prepared. > > Perhaps most importantly, in our recent development priorities survey > our use of Phabricator was the most common complaint by a fair margin, > both in case of respondents who have contributed patches and those who > have not. On the whole, past contributors and potential future > contributors alike have strongly indicated that they want a more > Git-like experience. Of course, this wasn't terribly surprising; this > is just the most recent case where contributors have made this > preference known. > > Frankly, in a sense it is hard to blame them. The fact that users need > to install a PHP tool, Arcanist, to contribute anything but > documentation patches has always seemed like unnecessary friction to me > and I would be quite happy to be rid of it. Indeed we have had a quite > healthy number of GitHub documentation patches since we started > accepting them. This makes me thing that there may indeed be potential > contributoes that we are leaving on the table. > > > # What to do > > With Rackspace support ending at the end of year, now may be a good > time to consider whether we really want to continue on this road. > Phabricator is great at code review but I am less and less certain that > it is worth the maintenance uncertainty and potential lost contributors > that it costs. > > Moreover, good alternatives seem closer at-hand than they were when we > deployed Phabricator. > > > ## Move to GitHub > > When people complain about our infrastructure, they often use GitHub as > the example of what they would like to see. However, realistically I > have a hard time seeing GitHub as a viable option. Its feature set is > simply > insufficient enough to handle the needs of a larger project like GHC > without significant external tooling (as seen in the case of Rust-lang). > > The concrete reasons have been well-documented in previous discussions > but, to summarize, > > * its review functionality is extremely painful to use with larger > patches > > * rebased patches lead to extreme confusion and lost review comments > > * it lacks support for pre-receive hooks, which serve as a last line of > defense to prevent unintended submodule changes > > * its inability to deal with external tickets is problematic > > * there is essentially no possibility that we could eventually migrate > GHC's tickets to GitHub's ticket tracker without considerable data > loss (much less manage the ticket load that would result), meaning > that we would forever be stuck with maintaining Trac. > > * on a personal note, its search functionality has often left me > empty-handed > > On the whole, these issues seem pretty hard to surmount. > > > ## Move to GitLab > > In using GitLab for another project over the past months I have been > positively surprised by its quality. It handles rebased merge requests > far better than GitHub, has functional search, and quite a usable review > interface. Furthermore, upstream has been extremely responsive to > suggestions for improvement [1]. Even out-of-the-box it seems to be > flexible enough to accommodate our needs, supporting integration with > external issue trackers, having reasonable release management features, > and support for code owners to automate review triaging (replacing much > of the functionality of Phabricator's Herald). > > Finally, other FOSS projects' [3] recent migrations from Phabrictor to > GitLab have shown that GitLab-the-company is quite willing to offer help > when needed. I took some time this weekend to try setting up a quick GHC > instance [2] to play around with. Even after just a few hours of playing > around I think the result is surprisingly usable. > > Out of curiosity I also played around with importing some tickets from > Trac (building on Matt Pickering's Trac-to-Maniphest migration tool). > With relatively little effort I was even able to get nearly all of our > tickets (as of 9 months ago) imported while preserving ticket numbers > (although there are naturally a few wrinkles that would need to be > worked out). Naturally, I think we should treat the question of ticket > tracker migration as an orthogonal one to code review, but it is good to > know that this is possible. > > > ## Continue with Phabricator > > Continuing with Phabricator is of course an option. Its review > functionality is great and it has served us reasonably well. However, > compared to GitLab and even GitHub of today its features seem less > distinguished than they once did. Moreover, the prospect of having to > maintain a largely stagnant product with no support strikes me as a > slightly dangerous game to play. Working around the issues we have > recently encountered has already cost a non-negligible amount of time. > > > # The bottom line > > If it wasn't clear already, I think that we should strongly consider a > move to GitLab. At this point it seems clear that it isn't going to > vanish, has a steady pace of development, is featureful, and available. > > However, these are just my thoughts. What do you think? > > Cheers, > > - Ben > > > [1] 11.4 will ship with a file tree view in the code review interface, > which I reported > (https://gitlab.com/gitlab-org/gitlab-ce/issues/46474) as being is > one of the Phabricator features I missed the most during review > > [2] https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641 > > [3] The GNOME and freedesktop.org projects have recently migrated, the > former from a hodge-podge of self-hosted services and the latter > from Phabricator > > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arian.vanputten at gmail.com Tue Oct 30 09:16:59 2018 From: arian.vanputten at gmail.com (Arian van Putten) Date: Tue, 30 Oct 2018 10:16:59 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: Gitlab has built-in CI support. This means it's well-integrated. I would expect the CI to improve. On Tue, Oct 30, 2018, 10:08 Simon Marlow wrote: > I'm entirely happy to move, provided (1) whatever we move to provides the > functionality we need, and (2) it's clearly what the community wants > (considering both current and future contributors). In the past when moving > to GitHub was brought up, there were a handful of core contributors who > argued strongly in favour of Phabricator, do we think that's changed? Do we > have any indication of whether the survey respondents who were > anti-Phabricator would be pro- or anti-GitLab? > > Personally I'd like to optimise for more code review, because I think that > more than anything else will increase quality and community ownership of > the project. If using new tooling will make code review a more central part > of our workflow, then that would be a good thing. Right now I think we're > very Trac-centric, and the integration between Trac and Phabricator isn't > great; if we could move to a solution with tighter integration between > tickets/code-review/wiki, that would be an improvement in my view. But not > GitHub, for the reasons you gave. > > Would GitLab solve the CI issues? I don't think you mentioned that > explicitly. > > Cheers > Simon > > On Tue, 30 Oct 2018 at 04:54, Ben Gamari wrote: > >> >> TL;DR. For several reasons I think we should consider alternatives to >> Phabricator. My view is that GitLab seems like the best option. >> >> >> Hello everyone, >> >> Over the past year I have been growing increasingly weary of our >> continued dependence on Phabricator. Without a doubt, its code review >> interface is the best I have used. However, for a myriad of reasons I >> am recently questioning whether it is still the best tool for GHC's >> needs. >> >> >> # The problem >> >> There are a number of reasons why I am currently uncertain about >> Phabricator. >> >> For one, at this point we have no options for support in the event that >> something goes wrong as the company responsible for Phabricator, >> Phacility, has closed their support channels to non-paying customers. >> Furthermore, in the past year or two Phacility has been placing their >> development resources in the parts their customers pay them for, which >> appear to be much different that the parts that we actively use. For >> this reason, some parts that we rely on seem oddly half-finished. >> >> This concern was recently underscored by some rather unfortunate >> misfeatures in Harbormaster which resulted in broken CI after the >> Hadrian merge and now apparent bugs which have made it difficult to >> migrate to the CircleCI integration we previously prepared. >> >> Perhaps most importantly, in our recent development priorities survey >> our use of Phabricator was the most common complaint by a fair margin, >> both in case of respondents who have contributed patches and those who >> have not. On the whole, past contributors and potential future >> contributors alike have strongly indicated that they want a more >> Git-like experience. Of course, this wasn't terribly surprising; this >> is just the most recent case where contributors have made this >> preference known. >> >> Frankly, in a sense it is hard to blame them. The fact that users need >> to install a PHP tool, Arcanist, to contribute anything but >> documentation patches has always seemed like unnecessary friction to me >> and I would be quite happy to be rid of it. Indeed we have had a quite >> healthy number of GitHub documentation patches since we started >> accepting them. This makes me thing that there may indeed be potential >> contributoes that we are leaving on the table. >> >> >> # What to do >> >> With Rackspace support ending at the end of year, now may be a good >> time to consider whether we really want to continue on this road. >> Phabricator is great at code review but I am less and less certain that >> it is worth the maintenance uncertainty and potential lost contributors >> that it costs. >> >> Moreover, good alternatives seem closer at-hand than they were when we >> deployed Phabricator. >> >> >> ## Move to GitHub >> >> When people complain about our infrastructure, they often use GitHub as >> the example of what they would like to see. However, realistically I >> have a hard time seeing GitHub as a viable option. Its feature set is >> simply >> insufficient enough to handle the needs of a larger project like GHC >> without significant external tooling (as seen in the case of Rust-lang). >> >> The concrete reasons have been well-documented in previous discussions >> but, to summarize, >> >> * its review functionality is extremely painful to use with larger >> patches >> >> * rebased patches lead to extreme confusion and lost review comments >> >> * it lacks support for pre-receive hooks, which serve as a last line of >> defense to prevent unintended submodule changes >> >> * its inability to deal with external tickets is problematic >> >> * there is essentially no possibility that we could eventually migrate >> GHC's tickets to GitHub's ticket tracker without considerable data >> loss (much less manage the ticket load that would result), meaning >> that we would forever be stuck with maintaining Trac. >> >> * on a personal note, its search functionality has often left me >> empty-handed >> >> On the whole, these issues seem pretty hard to surmount. >> >> >> ## Move to GitLab >> >> In using GitLab for another project over the past months I have been >> positively surprised by its quality. It handles rebased merge requests >> far better than GitHub, has functional search, and quite a usable review >> interface. Furthermore, upstream has been extremely responsive to >> suggestions for improvement [1]. Even out-of-the-box it seems to be >> flexible enough to accommodate our needs, supporting integration with >> external issue trackers, having reasonable release management features, >> and support for code owners to automate review triaging (replacing much >> of the functionality of Phabricator's Herald). >> >> Finally, other FOSS projects' [3] recent migrations from Phabrictor to >> GitLab have shown that GitLab-the-company is quite willing to offer help >> when needed. I took some time this weekend to try setting up a quick GHC >> instance [2] to play around with. Even after just a few hours of playing >> around I think the result is surprisingly usable. >> >> Out of curiosity I also played around with importing some tickets from >> Trac (building on Matt Pickering's Trac-to-Maniphest migration tool). >> With relatively little effort I was even able to get nearly all of our >> tickets (as of 9 months ago) imported while preserving ticket numbers >> (although there are naturally a few wrinkles that would need to be >> worked out). Naturally, I think we should treat the question of ticket >> tracker migration as an orthogonal one to code review, but it is good to >> know that this is possible. >> >> >> ## Continue with Phabricator >> >> Continuing with Phabricator is of course an option. Its review >> functionality is great and it has served us reasonably well. However, >> compared to GitLab and even GitHub of today its features seem less >> distinguished than they once did. Moreover, the prospect of having to >> maintain a largely stagnant product with no support strikes me as a >> slightly dangerous game to play. Working around the issues we have >> recently encountered has already cost a non-negligible amount of time. >> >> >> # The bottom line >> >> If it wasn't clear already, I think that we should strongly consider a >> move to GitLab. At this point it seems clear that it isn't going to >> vanish, has a steady pace of development, is featureful, and available. >> >> However, these are just my thoughts. What do you think? >> >> Cheers, >> >> - Ben >> >> >> [1] 11.4 will ship with a file tree view in the code review interface, >> which I reported >> (https://gitlab.com/gitlab-org/gitlab-ce/issues/46474) as being is >> one of the Phabricator features I missed the most during review >> >> [2] https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641 >> >> [3] The GNOME and freedesktop.org projects have recently migrated, the >> former from a hodge-podge of self-hosted services and the latter >> from Phabricator >> >> _______________________________________________ >> Ghc-devops-group mailing list >> Ghc-devops-group at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Tue Oct 30 09:45:40 2018 From: david at well-typed.com (David Feuer) Date: Tue, 30 Oct 2018 05:45:40 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87zhuw2fw2.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: <460df54f-817f-4abb-8cc2-5f4dc26397e8@well-typed.com> What's to prevent GitLab from doing what Phabricator has once enough companies have committed to it? ⁣David Feuer Well-Typed Consultant​ On Oct 30, 2018, 12:55 AM, at 12:55 AM, Ben Gamari wrote: > >TL;DR. For several reasons I think we should consider alternatives to > Phabricator. My view is that GitLab seems like the best option. > > >Hello everyone, > >Over the past year I have been growing increasingly weary of our >continued dependence on Phabricator. Without a doubt, its code review >interface is the best I have used. However, for a myriad of reasons I >am recently questioning whether it is still the best tool for GHC's >needs. > > ># The problem > >There are a number of reasons why I am currently uncertain about >Phabricator. > >For one, at this point we have no options for support in the event that >something goes wrong as the company responsible for Phabricator, >Phacility, has closed their support channels to non-paying customers. >Furthermore, in the past year or two Phacility has been placing their >development resources in the parts their customers pay them for, which >appear to be much different that the parts that we actively use. For >this reason, some parts that we rely on seem oddly half-finished. > >This concern was recently underscored by some rather unfortunate >misfeatures in Harbormaster which resulted in broken CI after the >Hadrian merge and now apparent bugs which have made it difficult to >migrate to the CircleCI integration we previously prepared. > >Perhaps most importantly, in our recent development priorities survey >our use of Phabricator was the most common complaint by a fair margin, >both in case of respondents who have contributed patches and those who >have not. On the whole, past contributors and potential future >contributors alike have strongly indicated that they want a more >Git-like experience. Of course, this wasn't terribly surprising; this >is just the most recent case where contributors have made this >preference known. > >Frankly, in a sense it is hard to blame them. The fact that users need >to install a PHP tool, Arcanist, to contribute anything but >documentation patches has always seemed like unnecessary friction to me >and I would be quite happy to be rid of it. Indeed we have had a quite >healthy number of GitHub documentation patches since we started >accepting them. This makes me thing that there may indeed be potential >contributoes that we are leaving on the table. > > ># What to do > >With Rackspace support ending at the end of year, now may be a good >time to consider whether we really want to continue on this road. >Phabricator is great at code review but I am less and less certain that >it is worth the maintenance uncertainty and potential lost contributors >that it costs. > >Moreover, good alternatives seem closer at-hand than they were when we >deployed Phabricator. > > >## Move to GitHub > >When people complain about our infrastructure, they often use GitHub as >the example of what they would like to see. However, realistically I >have a hard time seeing GitHub as a viable option. Its feature set is >simply >insufficient enough to handle the needs of a larger project like GHC >without significant external tooling (as seen in the case of >Rust-lang). > >The concrete reasons have been well-documented in previous discussions >but, to summarize, > > * its review functionality is extremely painful to use with larger > patches > > * rebased patches lead to extreme confusion and lost review comments > >* it lacks support for pre-receive hooks, which serve as a last line of > defense to prevent unintended submodule changes > > * its inability to deal with external tickets is problematic > > * there is essentially no possibility that we could eventually migrate > GHC's tickets to GitHub's ticket tracker without considerable data > loss (much less manage the ticket load that would result), meaning > that we would forever be stuck with maintaining Trac. > > * on a personal note, its search functionality has often left me > empty-handed > >On the whole, these issues seem pretty hard to surmount. > > >## Move to GitLab > >In using GitLab for another project over the past months I have been >positively surprised by its quality. It handles rebased merge requests >far better than GitHub, has functional search, and quite a usable >review >interface. Furthermore, upstream has been extremely responsive to >suggestions for improvement [1]. Even out-of-the-box it seems to be >flexible enough to accommodate our needs, supporting integration with >external issue trackers, having reasonable release management features, >and support for code owners to automate review triaging (replacing much >of the functionality of Phabricator's Herald). > >Finally, other FOSS projects' [3] recent migrations from Phabrictor to >GitLab have shown that GitLab-the-company is quite willing to offer >help >when needed. I took some time this weekend to try setting up a quick >GHC >instance [2] to play around with. Even after just a few hours of >playing >around I think the result is surprisingly usable. > >Out of curiosity I also played around with importing some tickets from >Trac (building on Matt Pickering's Trac-to-Maniphest migration tool). >With relatively little effort I was even able to get nearly all of our >tickets (as of 9 months ago) imported while preserving ticket numbers >(although there are naturally a few wrinkles that would need to be >worked out). Naturally, I think we should treat the question of ticket >tracker migration as an orthogonal one to code review, but it is good >to >know that this is possible. > > >## Continue with Phabricator > >Continuing with Phabricator is of course an option. Its review >functionality is great and it has served us reasonably well. However, >compared to GitLab and even GitHub of today its features seem less >distinguished than they once did. Moreover, the prospect of having to >maintain a largely stagnant product with no support strikes me as a >slightly dangerous game to play. Working around the issues we have >recently encountered has already cost a non-negligible amount of time. > > ># The bottom line > >If it wasn't clear already, I think that we should strongly consider a >move to GitLab. At this point it seems clear that it isn't going to >vanish, has a steady pace of development, is featureful, and available. > >However, these are just my thoughts. What do you think? > >Cheers, > >- Ben > > >[1] 11.4 will ship with a file tree view in the code review interface, > which I reported > (https://gitlab.com/gitlab-org/gitlab-ce/issues/46474) as being is > one of the Phabricator features I missed the most during review > >[2] https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641 > >[3] The GNOME and freedesktop.org projects have recently migrated, the > former from a hodge-podge of self-hosted services and the latter > from Phabricator > > > >------------------------------------------------------------------------ > >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Tue Oct 30 12:39:48 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 30 Oct 2018 13:39:48 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87zhuw2fw2.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> Hi Ben, Thanks a lot for the summary of the situation. As you know, I do dislike Phabricator for the many reasons that you are listing, and it would be nice to finally move to a better system. In particular, it is worth emphasising the fact highlighted by the survey, namely that "Phabricator was the most common complaint by a fair margin, both in case of respondents who have contributed patches and those who have not. On the whole, past contributors and potential future contributors alike have strongly indicated that they want a more Git-like experience.” One the one hand, we want broader participation in GHC development; on the other hand, we constantly ignore the single largest source of frustration for contributors. That just doesn’t make a lot of sense to me, even if it can be explained by the inertia of some existing developers. Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At least, that is my current understanding. Please correct me if I am wrong.) Given that large organisations work with large code bases on GitHub, I am still puzzled why GHC somehow cannot do that. (I do understand that the dev process that has been established within GHC is naturally focused around Phabricator and its tools. However, that doesn’t mean it couldn’t be changed to work as well as before, but with another tool.) In any case, I think, you didn’t mention one of the options we did discuss previously, namely to use GitHub together with a service that adds more sophisticated code review functionality, such as https://reviewable.io This would solve the CI issues without further ado. Cheers, Manuel > Am 30.10.2018 um 05:54 schrieb Ben Gamari : > > > TL;DR. For several reasons I think we should consider alternatives to > Phabricator. My view is that GitLab seems like the best option. > > > Hello everyone, > > Over the past year I have been growing increasingly weary of our > continued dependence on Phabricator. Without a doubt, its code review > interface is the best I have used. However, for a myriad of reasons I > am recently questioning whether it is still the best tool for GHC's > needs. > > > # The problem > > There are a number of reasons why I am currently uncertain about > Phabricator. > > For one, at this point we have no options for support in the event that > something goes wrong as the company responsible for Phabricator, > Phacility, has closed their support channels to non-paying customers. > Furthermore, in the past year or two Phacility has been placing their > development resources in the parts their customers pay them for, which > appear to be much different that the parts that we actively use. For > this reason, some parts that we rely on seem oddly half-finished. > > This concern was recently underscored by some rather unfortunate > misfeatures in Harbormaster which resulted in broken CI after the > Hadrian merge and now apparent bugs which have made it difficult to > migrate to the CircleCI integration we previously prepared. > > Perhaps most importantly, in our recent development priorities survey > our use of Phabricator was the most common complaint by a fair margin, > both in case of respondents who have contributed patches and those who > have not. On the whole, past contributors and potential future > contributors alike have strongly indicated that they want a more > Git-like experience. Of course, this wasn't terribly surprising; this > is just the most recent case where contributors have made this > preference known. > > Frankly, in a sense it is hard to blame them. The fact that users need > to install a PHP tool, Arcanist, to contribute anything but > documentation patches has always seemed like unnecessary friction to me > and I would be quite happy to be rid of it. Indeed we have had a quite > healthy number of GitHub documentation patches since we started > accepting them. This makes me thing that there may indeed be potential > contributoes that we are leaving on the table. > > > # What to do > > With Rackspace support ending at the end of year, now may be a good > time to consider whether we really want to continue on this road. > Phabricator is great at code review but I am less and less certain that > it is worth the maintenance uncertainty and potential lost contributors > that it costs. > > Moreover, good alternatives seem closer at-hand than they were when we > deployed Phabricator. > > > ## Move to GitHub > > When people complain about our infrastructure, they often use GitHub as > the example of what they would like to see. However, realistically I > have a hard time seeing GitHub as a viable option. Its feature set is simply > insufficient enough to handle the needs of a larger project like GHC > without significant external tooling (as seen in the case of Rust-lang). > > The concrete reasons have been well-documented in previous discussions > but, to summarize, > > * its review functionality is extremely painful to use with larger > patches > > * rebased patches lead to extreme confusion and lost review comments > > * it lacks support for pre-receive hooks, which serve as a last line of > defense to prevent unintended submodule changes > > * its inability to deal with external tickets is problematic > > * there is essentially no possibility that we could eventually migrate > GHC's tickets to GitHub's ticket tracker without considerable data > loss (much less manage the ticket load that would result), meaning > that we would forever be stuck with maintaining Trac. > > * on a personal note, its search functionality has often left me > empty-handed > > On the whole, these issues seem pretty hard to surmount. > > > ## Move to GitLab > > In using GitLab for another project over the past months I have been > positively surprised by its quality. It handles rebased merge requests > far better than GitHub, has functional search, and quite a usable review > interface. Furthermore, upstream has been extremely responsive to > suggestions for improvement [1]. Even out-of-the-box it seems to be > flexible enough to accommodate our needs, supporting integration with > external issue trackers, having reasonable release management features, > and support for code owners to automate review triaging (replacing much > of the functionality of Phabricator's Herald). > > Finally, other FOSS projects' [3] recent migrations from Phabrictor to > GitLab have shown that GitLab-the-company is quite willing to offer help > when needed. I took some time this weekend to try setting up a quick GHC > instance [2] to play around with. Even after just a few hours of playing > around I think the result is surprisingly usable. > > Out of curiosity I also played around with importing some tickets from > Trac (building on Matt Pickering's Trac-to-Maniphest migration tool). > With relatively little effort I was even able to get nearly all of our > tickets (as of 9 months ago) imported while preserving ticket numbers > (although there are naturally a few wrinkles that would need to be > worked out). Naturally, I think we should treat the question of ticket > tracker migration as an orthogonal one to code review, but it is good to > know that this is possible. > > > ## Continue with Phabricator > > Continuing with Phabricator is of course an option. Its review > functionality is great and it has served us reasonably well. However, > compared to GitLab and even GitHub of today its features seem less > distinguished than they once did. Moreover, the prospect of having to > maintain a largely stagnant product with no support strikes me as a > slightly dangerous game to play. Working around the issues we have > recently encountered has already cost a non-negligible amount of time. > > > # The bottom line > > If it wasn't clear already, I think that we should strongly consider a > move to GitLab. At this point it seems clear that it isn't going to > vanish, has a steady pace of development, is featureful, and available. > > However, these are just my thoughts. What do you think? > > Cheers, > > - Ben > > > [1] 11.4 will ship with a file tree view in the code review interface, > which I reported > (https://gitlab.com/gitlab-org/gitlab-ce/issues/46474) as being is > one of the Phabricator features I missed the most during review > > [2] https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641 > > [3] The GNOME and freedesktop.org projects have recently migrated, the > former from a hodge-podge of self-hosted services and the latter > from Phabricator > > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Oct 30 11:53:18 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 30 Oct 2018 11:53:18 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87zhuw2fw2.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: The compelling argument against Phabricator is that (as Ben mentions) parts of the product have remained unfinished whilst seemingly low-priority features are worked on for months. I think at the start Austin had a lot of success interacting with the maintainers but now you can't make a new ticket unless you are a paying customer. A compelling argument to move to gitlab is the possibility of tighter integration between the patches and tickets. I'm saying this as someone who much prefers using arcanist and the phabricator diff model to the git PR model but at the end of the day, everyone who contributes to GHC is able to use both models as most projects are hosted on github. I would be interested in reading more about the GNOME and freedesktop switch to gitlab. In particular the technical details of the migration. So I fully support Ben's judgement here and hope that we can make a decision with haste. Cheers, Matt On Tue, Oct 30, 2018 at 4:55 AM Ben Gamari wrote: > > > TL;DR. For several reasons I think we should consider alternatives to > Phabricator. My view is that GitLab seems like the best option. > > > Hello everyone, > > Over the past year I have been growing increasingly weary of our > continued dependence on Phabricator. Without a doubt, its code review > interface is the best I have used. However, for a myriad of reasons I > am recently questioning whether it is still the best tool for GHC's > needs. > > > # The problem > > There are a number of reasons why I am currently uncertain about > Phabricator. > > For one, at this point we have no options for support in the event that > something goes wrong as the company responsible for Phabricator, > Phacility, has closed their support channels to non-paying customers. > Furthermore, in the past year or two Phacility has been placing their > development resources in the parts their customers pay them for, which > appear to be much different that the parts that we actively use. For > this reason, some parts that we rely on seem oddly half-finished. > > This concern was recently underscored by some rather unfortunate > misfeatures in Harbormaster which resulted in broken CI after the > Hadrian merge and now apparent bugs which have made it difficult to > migrate to the CircleCI integration we previously prepared. > > Perhaps most importantly, in our recent development priorities survey > our use of Phabricator was the most common complaint by a fair margin, > both in case of respondents who have contributed patches and those who > have not. On the whole, past contributors and potential future > contributors alike have strongly indicated that they want a more > Git-like experience. Of course, this wasn't terribly surprising; this > is just the most recent case where contributors have made this > preference known. > > Frankly, in a sense it is hard to blame them. The fact that users need > to install a PHP tool, Arcanist, to contribute anything but > documentation patches has always seemed like unnecessary friction to me > and I would be quite happy to be rid of it. Indeed we have had a quite > healthy number of GitHub documentation patches since we started > accepting them. This makes me thing that there may indeed be potential > contributoes that we are leaving on the table. > > > # What to do > > With Rackspace support ending at the end of year, now may be a good > time to consider whether we really want to continue on this road. > Phabricator is great at code review but I am less and less certain that > it is worth the maintenance uncertainty and potential lost contributors > that it costs. > > Moreover, good alternatives seem closer at-hand than they were when we > deployed Phabricator. > > > ## Move to GitHub > > When people complain about our infrastructure, they often use GitHub as > the example of what they would like to see. However, realistically I > have a hard time seeing GitHub as a viable option. Its feature set is simply > insufficient enough to handle the needs of a larger project like GHC > without significant external tooling (as seen in the case of Rust-lang). > > The concrete reasons have been well-documented in previous discussions > but, to summarize, > > * its review functionality is extremely painful to use with larger > patches > > * rebased patches lead to extreme confusion and lost review comments > > * it lacks support for pre-receive hooks, which serve as a last line of > defense to prevent unintended submodule changes > > * its inability to deal with external tickets is problematic > > * there is essentially no possibility that we could eventually migrate > GHC's tickets to GitHub's ticket tracker without considerable data > loss (much less manage the ticket load that would result), meaning > that we would forever be stuck with maintaining Trac. > > * on a personal note, its search functionality has often left me > empty-handed > > On the whole, these issues seem pretty hard to surmount. > > > ## Move to GitLab > > In using GitLab for another project over the past months I have been > positively surprised by its quality. It handles rebased merge requests > far better than GitHub, has functional search, and quite a usable review > interface. Furthermore, upstream has been extremely responsive to > suggestions for improvement [1]. Even out-of-the-box it seems to be > flexible enough to accommodate our needs, supporting integration with > external issue trackers, having reasonable release management features, > and support for code owners to automate review triaging (replacing much > of the functionality of Phabricator's Herald). > > Finally, other FOSS projects' [3] recent migrations from Phabrictor to > GitLab have shown that GitLab-the-company is quite willing to offer help > when needed. I took some time this weekend to try setting up a quick GHC > instance [2] to play around with. Even after just a few hours of playing > around I think the result is surprisingly usable. > > Out of curiosity I also played around with importing some tickets from > Trac (building on Matt Pickering's Trac-to-Maniphest migration tool). > With relatively little effort I was even able to get nearly all of our > tickets (as of 9 months ago) imported while preserving ticket numbers > (although there are naturally a few wrinkles that would need to be > worked out). Naturally, I think we should treat the question of ticket > tracker migration as an orthogonal one to code review, but it is good to > know that this is possible. > > > ## Continue with Phabricator > > Continuing with Phabricator is of course an option. Its review > functionality is great and it has served us reasonably well. However, > compared to GitLab and even GitHub of today its features seem less > distinguished than they once did. Moreover, the prospect of having to > maintain a largely stagnant product with no support strikes me as a > slightly dangerous game to play. Working around the issues we have > recently encountered has already cost a non-negligible amount of time. > > > # The bottom line > > If it wasn't clear already, I think that we should strongly consider a > move to GitLab. At this point it seems clear that it isn't going to > vanish, has a steady pace of development, is featureful, and available. > > However, these are just my thoughts. What do you think? > > Cheers, > > - Ben > > > [1] 11.4 will ship with a file tree view in the code review interface, > which I reported > (https://gitlab.com/gitlab-org/gitlab-ce/issues/46474) as being is > one of the Phabricator features I missed the most during review > > [2] https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641 > > [3] The GNOME and freedesktop.org projects have recently migrated, the > former from a hodge-podge of self-hosted services and the latter > from Phabricator > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From andres at well-typed.com Tue Oct 30 13:03:43 2018 From: andres at well-typed.com (Andres =?utf-8?Q?L=C3=B6h?=) Date: Tue, 30 Oct 2018 13:03:43 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> Message-ID: <20181030130343.bf3f3qydf6jj47be@nullzig.kosmikus.org> Hi. > Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At least, that is my current understanding. Please correct me if I am wrong.) Just a clarification on this issue. I might be wrong, but my understanding is that: - Gitlab offers its own Gitlab CI, but it doesn't force you to use it, and doesn't prevent you from using other CI solutions. - Web-based CI solutions have to specifically support Gitlab for you to be able to use them with Gitlab. - To my knowledge, Appveyor supports Gitlab, but Circle and Travis currently do not. I know that there are issues open for these systems to support Gitlab, but I have no idea whether this is likely to happen anytime soon. For example, for Circle, the discussion seems to be here: https://circleci.com/ideas/?idea=CCI-I-248 Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England From ben at well-typed.com Tue Oct 30 13:50:26 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Oct 2018 09:50:26 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <460df54f-817f-4abb-8cc2-5f4dc26397e8@well-typed.com> References: <87zhuw2fw2.fsf@smart-cactus.org> <460df54f-817f-4abb-8cc2-5f4dc26397e8@well-typed.com> Message-ID: <87pnvr35nm.fsf@smart-cactus.org> David Feuer writes: > What's to prevent GitLab from doing what Phabricator has once enough > companies have committed to it? > In principle, nothing. However, in general GitLab-the-company seems significantly more devoted to the idea of GitLab as an open-source project than Phacility was to Phabricator. In truth, Phabricator was never really an healthy FOSS project. Yes, the source was available but the maintainers were quite clear that they have no intention of accepting unsolicited patches. GitLab, on the other hand, encourages external contributors, has actively supported adoption by open source projects and has an active set of maintainers. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue Oct 30 13:51:22 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Oct 2018 09:51:22 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <20181030130343.bf3f3qydf6jj47be@nullzig.kosmikus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <20181030130343.bf3f3qydf6jj47be@nullzig.kosmikus.org> Message-ID: <87o9bb35lz.fsf@smart-cactus.org> Andres Löh writes: > Hi. > >> Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At least, that is my current understanding. Please correct me if I am wrong.) > > Just a clarification on this issue. > > I might be wrong, but my understanding is that: > > - Gitlab offers its own Gitlab CI, but it doesn't force you to use it, > and doesn't prevent you from using other CI solutions. > > - Web-based CI solutions have to specifically support Gitlab for you to > be able to use them with Gitlab. > > - To my knowledge, Appveyor supports Gitlab, but Circle and Travis > currently do not. I know that there are issues open for these systems > to support Gitlab, but I have no idea whether this is likely to happen > anytime soon. For example, for Circle, the discussion seems to be > here: https://circleci.com/ideas/?idea=CCI-I-248 > That is entirely correct; however, we have already invested the effort to build a bridge between Phabricator and CircleCI (only to have deployment complicated by an apparent Phabricator bug). The implementation of this didn't take particularly long and I expect migrating this work to GitLab would be if anything easier (since GitLab has a more-standard REST interface than Phabricator's Conduit). Cheers, - ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue Oct 30 14:34:02 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Oct 2018 10:34:02 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> Message-ID: <87lg6f33my.fsf@smart-cactus.org> Manuel M T Chakravarty writes: > Hi Ben, > ... > > Given that large organisations work with large code bases on GitHub, I > am still puzzled why GHC somehow cannot do that. (I do understand that > the dev process that has been established within GHC is naturally > focused around Phabricator and its tools. However, that doesn’t mean > it couldn’t be changed to work as well as before, but with another > tool.) > > In any case, I think, you didn’t mention one of the options we did > discuss previously, namely to use GitHub together with a service that > adds more sophisticated code review functionality, such as > > https://reviewable.io > Some of the issues I list with GitHub are entirely orthogonal to GitHub's code review tool. While Rust has shown that large open-source projects can use GitHub, they have also demonstrated that it requires a remarkable amount of automation (I counted three distinct bots in use on the first random pull request I opened). In my own discussions with Rust-lang maintainers they have noted that even with this tooling they are still somewhat unhappy with the amount of manual busywork working within GitHub requires. More generally, I think the move to CircleCI in a way underscores why I'm a bit hesitant to move to another silo. While it generally does "just work", there have been several cases where I have had to have multi-week interactions CircleCI support to work through inscrutable build issues. Moreover, we continue to be bit by the inability to prioritize jobs and, despite efforts, still have no ability to build for non-Linux/amd64 platforms. Consequently I'm rather skittish about moving to another platform where we have limited insight into issues, no influence over direction of development, and no ability to fix bugs where necessary. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From m at tweag.io Tue Oct 30 16:05:27 2018 From: m at tweag.io (Boespflug, Mathieu) Date: Tue, 30 Oct 2018 17:05:27 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87lg6f33my.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> Message-ID: Hi Ben, On Tue, 30 Oct 2018 at 15:34, Ben Gamari wrote: > > ... > > Some of the issues I list with GitHub are entirely orthogonal to > GitHub's code review tool. > > While Rust has shown that large open-source projects can use GitHub, > they have also demonstrated that it requires a remarkable amount of > automation. Could you say more about how this would affect GHC? The issues with GitHub that were listed in your original email are all to do with reviews (and to my knowledge addressed by layering reviewable.io on top of GitHub as Manuel says), except a couple. Cribbing from followup emails as well, I end up with the following list: * Poor integration with external issue trackers (or at any rate with Trac), I assume meaning, hard to transactionally close issues upon PR merge and other ticket status updates. * No merge-on-green-CI button. So keeping the review UX issues aside for a moment, are there other GitHub limitations that you anticipate would warrant automation bots à la Rust-lang? I'm not too worried about the CI story. The hard part with CircleCI isn't CircleCI, it's getting to a green CircleCI. But once we're there, moving to a green OtherCI shouldn't be much work. Best, Mathieu From ben at well-typed.com Tue Oct 30 17:47:45 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Oct 2018 13:47:45 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> Message-ID: <87y3af1g3n.fsf@smart-cactus.org> "Boespflug, Mathieu" writes: > Hi Ben, > > On Tue, 30 Oct 2018 at 15:34, Ben Gamari wrote: >> >> ... >> >> Some of the issues I list with GitHub are entirely orthogonal to >> GitHub's code review tool. >> >> While Rust has shown that large open-source projects can use GitHub, >> they have also demonstrated that it requires a remarkable amount of >> automation. > > Could you say more about how this would affect GHC? The issues with > GitHub that were listed in your original email are all to do with > reviews (and to my knowledge addressed by layering reviewable.io on > top of GitHub as Manuel says), except a couple. Cribbing from followup > emails as well, I end up with the following list: > It occurs to me that I never did sit down to write up my thoughts on reviewable. I tried doing a few reviews with it [1] and indeed it is quite good; in many ways it is comparable to Differential. It's a bit sluggish to load (loading a moderate-sized patch took over 15 seconds in Firefox) but after that it seems quite usable. The comment functionality is great; the ability to leave comments even on lines that were untouched by the patch is noted. However, it really feels like a band-aid, introducing another layer of indirection and a distinct conversation venue all to make up for what are plain deficiencies in GitHub's core product. Moreover, given that using it implies that we also need to buy in to the other deficiencies in GitHub's core product, it's not clear to me why we would go this direction when there are open-source, more featureful alternatives that also have a history of being adoption by large open-source projects. I suspect it will make little difference to contributors; one can authenticate to both with GitHub credentials and the UX is fairly similar. To me, the choice seems fairly clear-cut. [1] Admittedly my these were single-shot reviews and lacked the usual back-and-forth that one typically has during review, but on moderate-size patches, so I think they are fairly representative. > * Poor integration with external issue trackers (or at any rate with > Trac), I assume meaning, hard to transactionally close issues upon PR > merge and other ticket status updates. > * No merge-on-green-CI button. > > So keeping the review UX issues aside for a moment, are there other > GitHub limitations that you anticipate would warrant automation bots à > la Rust-lang? > Ultimately Rust's tools all exist for a reason. Bors works around GitHub's lacking ability to merge-on-CI-pass, Highfive addresses the lack of a flexible code owner notification system, among other things. Both of these are features that we either have already or would like to have. Furthermore, we already recognize that there are holes in our current CI story: relying on cross-compilation to validate non-Linux/amd64 architectures both complicates troubleshooting and requires that we fix issues in GHC's build system that I would rather not tie CI to. GitLab would allow us to potentially continue using CircleCI for "normal" platforms while giving us the ability to easily fill this holes with GitLab's native CI support (which I have used in a few projects; it is both easy to configure and flexible). On the whole, I simply see very few advantages to using GitHub over GitLab; the latter simply seems to me to be a generally superior product. Furthermore, we should remember that no product will be perfect; in light of this it is important to consider a) the openness of the implementation, and b) the responsiveness of the upstream developer. GitLab has the advantage of being open-source with an extremely responsive upstream; this stands in contrast to GitHub, where I have had straightforward pull requests [2] languish for the better part of a year before being merged and deployed. [2] https://github.com/github/markup/pull/925 > I'm not too worried about the CI story. The hard part with CircleCI > isn't CircleCI, it's getting to a green CircleCI. But once we're > there, moving to a green OtherCI shouldn't be much work. > Right, and we are largely already there! Hadrian, Darwin, Fedora, and Debian/amd64 builds are all currently green; i386 is hours from passing (a regression recently snuck in which I pinned down this morning), the LLVM build is pending a fix for a long-standing critical bug (#14251), and we are now two tests away from slow validation being green. The remaining piece is moving differential validation to CircleCI. This was one of the motivations for starting this discussion. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue Oct 30 19:22:28 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Oct 2018 15:22:28 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: <87tvl31bps.fsf@smart-cactus.org> Simon Marlow writes: > I'm entirely happy to move, provided (1) whatever we move to provides the > functionality we need, and (2) it's clearly what the community wants > (considering both current and future contributors). In the past when moving > to GitHub was brought up, there were a handful of core contributors who > argued strongly in favour of Phabricator, do we think that's changed? Do we > have any indication of whether the survey respondents who were > anti-Phabricator would be pro- or anti-GitLab? > The comments fell into several buckets: a. Those who spoke in favor of GitHub in particular b. Those who spoke in favor of GitHub and GitLab c. Those who spoke against Phabricator I seem to recall that (a) was the largest group. No one explicitly stated that they would be against GitLab, although this is not terribly surprising given we didn't ask. Frankly I doubt there would be people who would actively support GitHub but not GitLab given how similar the workflows are. However, collecting data for this hunch is one of the reasons for this thread. > Personally I'd like to optimise for more code review, because I think that > more than anything else will increase quality and community ownership of > the project. If using new tooling will make code review a more central part > of our workflow, then that would be a good thing. Agreed, currently we have too few reviewers for the volume of code we are pushing into the tree. > Right now I think we're > very Trac-centric, and the integration between Trac and Phabricator isn't > great; if we could move to a solution with tighter integration between > tickets/code-review/wiki, that would be an improvement in my view. But not > GitHub, for the reasons you gave. > Yes, I agree. Currently I spend too much time keeping tickets in sync and this is almost entirely wasted time. > Would GitLab solve the CI issues? I don't think you mentioned that > explicitly. > It helps, yes. As Andres pointed out, Appveyor has native support for GitLab, which we use for Windows validation. Furthermore, GitLab's native CI would allow us to test non-x86 platforms. CircleCI lacks GitLab support however I believe the integration we have already developed to support integration with Phabricator could be easily adapted for GitLab. Moreover, given that the "Add GitLab support" request is at the top of CircleCI's feature request tracker, it seems likely that there will be native support in the future. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From m at tweag.io Tue Oct 30 21:50:48 2018 From: m at tweag.io (Boespflug, Mathieu) Date: Tue, 30 Oct 2018 22:50:48 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87y3af1g3n.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> <87y3af1g3n.fsf@smart-cactus.org> Message-ID: Hi Ben, On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote: > > ... > > It occurs to me that I never did sit down to write up my thoughts on > reviewable. I tried doing a few reviews with it [1] and indeed it is > quite good; in many ways it is comparable to Differential. [...] > However, it really feels like a band-aid, introducing another layer of > indirection and a distinct conversation venue all to make up for what > are plain deficiencies in GitHub's core product. Sure. That sounds fine to me though, or indeed no different than say, using GitHub XOR Gitlab for code hosting, Phabricator for review (and only for that), and Trac for tickets (not ideal but no worse than status quo). If Phabricator (the paid for hosted version) or Reviewable.io really are the superior review tools, and if as review tools they integrate seamlessy with GitHub (or Gitlab), then that's an option worth considering. The important things are: reducing the maintenance burden (by preferring hosted solutions) while still meeting developer requirements and supporting a workflow that is familiar to most. > > So keeping the review UX issues aside for a moment, are there other > > GitHub limitations that you anticipate would warrant automation bots à > > la Rust-lang? > > > Ultimately Rust's tools all exist for a reason. Bors works around > GitHub's lacking ability to merge-on-CI-pass, Highfive addresses the > lack of a flexible code owner notification system, among other things. > Both of these are features that we either have already or would like to > have. ... and I assume based on your positive assessment, are both out-of-the-box features of Gitlab that meet the requirements? > On the whole, I simply see very few advantages to using GitHub over > GitLab; the latter simply seems to me to be a generally superior product. That may well be the case. The main argument for GitHub is taking advantage of its network effect. But a big part of that is not having to manage a new set of credentials elsewhere, as well as remembering different user names for the same collaborators on different platforms. You're saying I can use my GitHub credentials to authenticate on Gitlab. So in the end we possibly wouldn't be losing much of that network effect. > > I'm not too worried about the CI story. The hard part with CircleCI > > isn't CircleCI, it's getting to a green CircleCI. But once we're > > there, moving to a green OtherCI shouldn't be much work. > > > Right, and we are largely already there! That's great to hear.