[GHC DevOps Group] Phabricator -> GitHub?

Tue Oct 10 07:19:17 UTC 2017

[RESENT MESSAGE — see https://mail.haskell.org/pipermail/ghc-devops-group/2017-October/000004.html]


> From: "Boespflug, Mathieu" <m at tweag.io>
> Subject: Aw: [GHC DevOps Group] Phabricator -> GitHub?
> Date: 10. Oktober 2017 um 08:10:39 GMT+11
> To: Simon Marlow <marlowsd at gmail.com>
> Cc: Manuel M T Chakravarty <manuel.chakravarty at tweag.io>, ghc-devops-group at haskell.org
> 
> Hi Simon,
> 
>>>> Secondly, the suggestion was only to use reviewable.io for particularly
>>>> heavy PRs.
>>> 
>>> 
>>> I think that would be worse, because we have some PRs going through
>>> different code review tools. On Phabricator I have a single dashboard that
>>> shows me which PRs are needing my attention, I don't want to have to visit
>>> two different tools to see that.
> 
> I agree with you that not having all PR's in a single dashboard would
> be very inconvenient. But note that even with reviewable.io (which I
> think really isn't very necessary at this point, but is at least an
> option), you'd still have a single dashboard, that dashboard being the
> GitHub PR dashboard you know currently.
> 
> The essential difference is that reviewable.io is not an alternate
> tool. It's an opt-in thin layer on top of GitHub.
> 
>>>> 
>>>> Thirdly, it still is much better than Phabricator on the new random tool
>>>> front because it requires no custom infrastructure and the PRs still go
>>>> through GitHub as usual.
>>> 
>>> 
>>> I do buy the custom infrastructure argument in general - setting up our
>>> own CI has definitely taken a lot of Ben's time. I actually really liked
>>> having Travis for my GHC fork on GitHub.  That was when it used to work,
>>> before our build exceeded what Travis would give us. So I guess that
>>> illustrates two things: custom infrastructure is nice when it works, but
>>> we're at the mercy of the suppliers.
> 
> Just another note here: these kinds of limits have proven "soft" in
> the past, in that the Travis CI folks have been willing to bump the
> limits for a large project like GHC. I'd be surprised if they weren't
> willing to bump these limits some more, especially for a highly
> visible open source project like GHC. In any case, I've had very good
> success setting up CI for Tweag I/O's GHC fork for linear types on top
> of CircleCI, which has the option run on faster machines, and also has
> less aggressive limits. I hear the Hadrian project still uses Travis
> CI to good effect. In terms of effort vs quality, to setup something
> that's a) uses only scalable resources, and b) is completely
> reproducible by anyone, both these hosted CI options proved to have a
> very good ratio indeed.
> Anfang der weitergeleiteten Nachricht:
> 
> Von: "Boespflug, Mathieu" <m at tweag.io>
> Betreff: Aw: [GHC DevOps Group] Phabricator -> GitHub?
> Datum: 10. Oktober 2017 um 08:10:39 GMT+11
> An: Simon Marlow <marlowsd at gmail.com>
> Kopie: Manuel M T Chakravarty <manuel.chakravarty at tweag.io>, ghc-devops-group at haskell.org
> 
> Hi Simon,
> 
>>>> Secondly, the suggestion was only to use reviewable.io for particularly
>>>> heavy PRs.
>>> 
>>> 
>>> I think that would be worse, because we have some PRs going through
>>> different code review tools. On Phabricator I have a single dashboard that
>>> shows me which PRs are needing my attention, I don't want to have to visit
>>> two different tools to see that.
> 
> I agree with you that not having all PR's in a single dashboard would
> be very inconvenient. But note that even with reviewable.io (which I
> think really isn't very necessary at this point, but is at least an
> option), you'd still have a single dashboard, that dashboard being the
> GitHub PR dashboard you know currently.
> 
> The essential difference is that reviewable.io is not an alternate
> tool. It's an opt-in thin layer on top of GitHub.
> 
>>>> 
>>>> Thirdly, it still is much better than Phabricator on the new random tool
>>>> front because it requires no custom infrastructure and the PRs still go
>>>> through GitHub as usual.
>>> 
>>> 
>>> I do buy the custom infrastructure argument in general - setting up our
>>> own CI has definitely taken a lot of Ben's time. I actually really liked
>>> having Travis for my GHC fork on GitHub.  That was when it used to work,
>>> before our build exceeded what Travis would give us. So I guess that
>>> illustrates two things: custom infrastructure is nice when it works, but
>>> we're at the mercy of the suppliers.
> 
> Just another note here: these kinds of limits have proven "soft" in
> the past, in that the Travis CI folks have been willing to bump the
> limits for a large project like GHC. I'd be surprised if they weren't
> willing to bump these limits some more, especially for a highly
> visible open source project like GHC. In any case, I've had very good
> success setting up CI for Tweag I/O's GHC fork for linear types on top
> of CircleCI, which has the option run on faster machines, and also has
> less aggressive limits. I hear the Hadrian project still uses Travis
> CI to good effect. In terms of effort vs quality, to setup something
> that's a) uses only scalable resources, and b) is completely
> reproducible by anyone, both these hosted CI options proved to have a
> very good ratio indeed.
> Anfang der weitergeleiteten Nachricht:
> 
> Von: "Boespflug, Mathieu" <m at tweag.io>
> Betreff: Aw: [GHC DevOps Group] Phabricator -> GitHub?
> Datum: 10. Oktober 2017 um 08:10:39 GMT+11
> An: Simon Marlow <marlowsd at gmail.com>
> Kopie: ghc-devops-group at haskell.org
> 
> Hi Simon,
> 
>>>> Secondly, the suggestion was only to use reviewable.io for particularly
>>>> heavy PRs.
>>> 
>>> 
>>> I think that would be worse, because we have some PRs going through
>>> different code review tools. On Phabricator I have a single dashboard that
>>> shows me which PRs are needing my attention, I don't want to have to visit
>>> two different tools to see that.
> 
> I agree with you that not having all PR's in a single dashboard would
> be very inconvenient. But note that even with reviewable.io (which I
> think really isn't very necessary at this point, but is at least an
> option), you'd still have a single dashboard, that dashboard being the
> GitHub PR dashboard you know currently.
> 
> The essential difference is that reviewable.io is not an alternate
> tool. It's an opt-in thin layer on top of GitHub.
> 
>>>> 
>>>> Thirdly, it still is much better than Phabricator on the new random tool
>>>> front because it requires no custom infrastructure and the PRs still go
>>>> through GitHub as usual.
>>> 
>>> 
>>> I do buy the custom infrastructure argument in general - setting up our
>>> own CI has definitely taken a lot of Ben's time. I actually really liked
>>> having Travis for my GHC fork on GitHub.  That was when it used to work,
>>> before our build exceeded what Travis would give us. So I guess that
>>> illustrates two things: custom infrastructure is nice when it works, but
>>> we're at the mercy of the suppliers.
> 
> Just another note here: these kinds of limits have proven "soft" in
> the past, in that the Travis CI folks have been willing to bump the
> limits for a large project like GHC. I'd be surprised if they weren't
> willing to bump these limits some more, especially for a highly
> visible open source project like GHC. In any case, I've had very good
> success setting up CI for Tweag I/O's GHC fork for linear types on top
> of CircleCI, which has the option run on faster machines, and also has
> less aggressive limits. I hear the Hadrian project still uses Travis
> CI to good effect. In terms of effort vs quality, to setup something
> that's a) uses only scalable resources, and b) is completely
> reproducible by anyone, both these hosted CI options proved to have a
> very good ratio indeed.
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://haskell.org/pipermail/ghc-devops-group/attachments/20171010/54e4ec5f/attachment-0001.html>