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 <marlo...@gmail.com> 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 <b...@well-typed.com> 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-gr...@haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group >> > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
