From michal.terepeta at gmail.com  Thu Nov  1 18:17:23 2018
From: michal.terepeta at gmail.com (Michal Terepeta)
Date: Thu, 1 Nov 2018 19:17:23 +0100
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org>
 <87lg6f33my.fsf@smart-cactus.org>
 <CAJ0eudoCo68G_36QoBBpwaMMTLMZYQ=fFd3hPtvT64_Uh_ho_A@mail.gmail.com>
 <87y3af1g3n.fsf@smart-cactus.org>
 <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
Message-ID: <CAEN7k7ngvbauDpkK_EUV+hs5V_82g9+yW7ttmuS-U8hPyNPFrg@mail.gmail.com>

Hope you don't mind if I add an opinion of a small/occasional
contributor to the thread.

Personally, I would prefer a move to GitHub. Mostly due to familiarity
and network effect (pretty much everyone is on GitHub).

But I would also consider a move to GitLab a big improvement over the
current Phab-based setup.  A git-based workflow would be great - I use
arc/Phab too rarely to really invest in learning them better. (I just
figured out the simplest way to use them that seems to work and I'm
sticking to it :) I haven't actually used GitLab before, but it seems
super easy to sign in using GitHub credentials and the interface seems
quite familiar.

One thing that was already mentioned is the ticket handling and I just
wanted to say "+1". I *really* dislike Trac - it's slow, unintuitive and
every time I use it I need to spend a couple of minutes to find the
guide to its own weird version of markdown... So a better place for
tickets that's tightly integrated with code code hosting/review tools
would be really cool! Which brings an interesting aspect of this
discussion - if I had to choose between "GitHub for code hosting/review
& Trac for tickets" vs "GitLab for everything", I'd prefer the latter.

- Michal


On Tue, Oct 30, 2018 at 10:51 PM Boespflug, Mathieu <m at tweag.io> wrote:

> Hi Ben,
>
> On Tue, 30 Oct 2018 at 18:47, Ben Gamari <ben at well-typed.com> 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.
> _______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181101/36909a7f/attachment.html>

From ben at well-typed.com  Thu Nov  1 22:43:11 2018
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 01 Nov 2018 18:43:11 -0400
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org>
 <87lg6f33my.fsf@smart-cactus.org>
 <CAJ0eudoCo68G_36QoBBpwaMMTLMZYQ=fFd3hPtvT64_Uh_ho_A@mail.gmail.com>
 <87y3af1g3n.fsf@smart-cactus.org>
 <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
Message-ID: <87y3aczaf8.fsf@smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> writes:

> Hi Ben,
>
> On Tue, 30 Oct 2018 at 18:47, Ben Gamari <ben at well-typed.com> wrote:

...

>
> 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.
>
Right; I believe that GitLab checks all of these boxes.

>> 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?
>
Yes, GitLab has support for both of these features natively.

>> 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.
>
Precisely, GitLab supports OAuth authentication, so one can login with
GitHub credentials.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181101/6a74b54e/attachment.sig>

From marlowsd at gmail.com  Fri Nov  2 08:13:37 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 2 Nov 2018 08:13:37 +0000
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <87tvl31bps.fsf@smart-cactus.org>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <87tvl31bps.fsf@smart-cactus.org>
Message-ID: <CANsrgPJDBx8ysVQm--y0SFaes82T7E1-VGcvieR0zjLXQuSnMA@mail.gmail.com>

What about the wiki? Can we migrate that off Trac too?

We'd have to keep redirects in place on ghc.haskell.org to avoid breaking
links to tickets and wiki pages from elsewhere.

If we really can do a stacked-diff-style workflow using PRs on GitLab then
that at least for me removes one of the big drawbacks of moving. But how
easy will it be to enforce that workflow and will it be going against the
grain on GitLab? I imagine people used to adding extra commits to a PR will
tend to do that rather than amending+rebasing. I suppose we can do a
squash-merge when committing to keep the history clean, but then
contributors have a choice - either do GitHub-style where you add commits
to a PR to update it and we squash on merge, OR Phabricator-style where you
keep the same set of commits and rebase the stack to update it. If you want
to do dependent commits then you have to use Phabricator style. Choices
between workflows make things more complicated for contributors, and that
worries me.

Does GitLab keep the history of a PR after it has been updated, like in
Phabricator? So we can see what happened between versions of a PR?

Cheers
Simon

On Tue, 30 Oct 2018 at 19:22, Ben Gamari <ben at well-typed.com> wrote:

> Simon Marlow <marlowsd at gmail.com> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181102/41313e89/attachment.html>

From ben at well-typed.com  Fri Nov  2 12:47:56 2018
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 02 Nov 2018 08:47:56 -0400
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CANsrgPJDBx8ysVQm--y0SFaes82T7E1-VGcvieR0zjLXQuSnMA@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <87tvl31bps.fsf@smart-cactus.org>
 <CANsrgPJDBx8ysVQm--y0SFaes82T7E1-VGcvieR0zjLXQuSnMA@mail.gmail.com>
Message-ID: <875zxfzlvs.fsf@smart-cactus.org>

Simon Marlow <marlowsd at gmail.com> writes:

> What about the wiki? Can we migrate that off Trac too?
>
Yes, we certainly can. As Herbert mentioned, some of the fancier markup
in Trac will require a bit of manual grooming. However, the basic idea
is easily implemented with the migration that I already developed.

> We'd have to keep redirects in place on ghc.haskell.org to avoid breaking
> links to tickets and wiki pages from elsewhere.
>
Yes, absolutely.

> If we really can do a stacked-diff-style workflow using PRs on GitLab then
> that at least for me removes one of the big drawbacks of moving. But how
> easy will it be to enforce that workflow and will it be going against the
> grain on GitLab? I imagine people used to adding extra commits to a PR will
> tend to do that rather than amending+rebasing. I suppose we can do a
> squash-merge when committing to keep the history clean, but then
> contributors have a choice - either do GitHub-style where you add commits
> to a PR to update it and we squash on merge, OR Phabricator-style where you
> keep the same set of commits and rebase the stack to update it. If you want
> to do dependent commits then you have to use Phabricator style. Choices
> between workflows make things more complicated for contributors, and that
> worries me.
>
This shouldn't be a problem. One can easily configure a project such
that users are *only* allowed to fast-forward/rebase, disallowing the
creation of merge commits.

> Does GitLab keep the history of a PR after it has been updated, like in
> Phabricator? So we can see what happened between versions of a PR?
>
Yes it does.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181102/b54f5a5e/attachment.sig>

From ben at smart-cactus.org  Thu Nov  1 22:43:37 2018
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 01 Nov 2018 18:43:37 -0400
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CAEN7k7ngvbauDpkK_EUV+hs5V_82g9+yW7ttmuS-U8hPyNPFrg@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org>
 <87lg6f33my.fsf@smart-cactus.org>
 <CAJ0eudoCo68G_36QoBBpwaMMTLMZYQ=fFd3hPtvT64_Uh_ho_A@mail.gmail.com>
 <87y3af1g3n.fsf@smart-cactus.org>
 <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
 <CAEN7k7ngvbauDpkK_EUV+hs5V_82g9+yW7ttmuS-U8hPyNPFrg@mail.gmail.com>
Message-ID: <87va5gzaeg.fsf@smart-cactus.org>

Michal Terepeta <michal.terepeta at gmail.com> writes:

> Hope you don't mind if I add an opinion of a small/occasional
> contributor to the thread.
>
> Personally, I would prefer a move to GitHub. Mostly due to familiarity
> and network effect (pretty much everyone is on GitHub).
>
> But I would also consider a move to GitLab a big improvement over the
> current Phab-based setup.  A git-based workflow would be great - I use
> arc/Phab too rarely to really invest in learning them better. (I just
> figured out the simplest way to use them that seems to work and I'm
> sticking to it :) I haven't actually used GitLab before, but it seems
> super easy to sign in using GitHub credentials and the interface seems
> quite familiar.
>
> One thing that was already mentioned is the ticket handling and I just
> wanted to say "+1". I *really* dislike Trac - it's slow, unintuitive and
> every time I use it I need to spend a couple of minutes to find the
> guide to its own weird version of markdown... So a better place for
> tickets that's tightly integrated with code code hosting/review tools
> would be really cool! Which brings an interesting aspect of this
> discussion - if I had to choose between "GitHub for code hosting/review
> & Trac for tickets" vs "GitLab for everything", I'd prefer the latter.
>
Thanks for this data point, Michal!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181101/711d7655/attachment.sig>

From vladislav at serokell.io  Thu Nov  1 23:27:15 2018
From: vladislav at serokell.io (Vladislav Zavialov)
Date: Fri, 2 Nov 2018 02:27:15 +0300
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <87va5gzaeg.fsf@smart-cactus.org>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org>
 <87lg6f33my.fsf@smart-cactus.org>
 <CAJ0eudoCo68G_36QoBBpwaMMTLMZYQ=fFd3hPtvT64_Uh_ho_A@mail.gmail.com>
 <87y3af1g3n.fsf@smart-cactus.org>
 <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
 <CAEN7k7ngvbauDpkK_EUV+hs5V_82g9+yW7ttmuS-U8hPyNPFrg@mail.gmail.com>
 <87va5gzaeg.fsf@smart-cactus.org>
Message-ID: <CAGL=qfHjasU7t27qJWVAcTePtE4j40588KzvDda5hCtANV=CPQ@mail.gmail.com>

To put my 2¢ – I will be happy with whatever service provides the most
reliable CI.

In terms of workflow, I like Ben's suggestion:

  * Consider a PR to be a stack of differentials, with each commit
being an atomic change in that stack.

From carter.schonwald at gmail.com  Thu Nov  1 23:34:01 2018
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 1 Nov 2018 19:34:01 -0400
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CAGL=qfHjasU7t27qJWVAcTePtE4j40588KzvDda5hCtANV=CPQ@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org>
 <87lg6f33my.fsf@smart-cactus.org>
 <CAJ0eudoCo68G_36QoBBpwaMMTLMZYQ=fFd3hPtvT64_Uh_ho_A@mail.gmail.com>
 <87y3af1g3n.fsf@smart-cactus.org>
 <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
 <CAEN7k7ngvbauDpkK_EUV+hs5V_82g9+yW7ttmuS-U8hPyNPFrg@mail.gmail.com>
 <87va5gzaeg.fsf@smart-cactus.org>
 <CAGL=qfHjasU7t27qJWVAcTePtE4j40588KzvDda5hCtANV=CPQ@mail.gmail.com>
Message-ID: <CAHYVw0yLt4xrQW5UZ05am1swE1Q7zvEEwmNaraLRv-JkcC1Hcw@mail.gmail.com>

For what it’s worth, I’ve never found phab / arc to be the bottle neck /
actual time consuming piece of doing anything for ghc

It’s defintely the nicest code review substrate I’ve engaged with

One question I have : how does the llvm org manage / handle their
phabricator instance and or ci substrate. Maybe they have wisdom that can
help ?

On Thu, Nov 1, 2018 at 7:27 PM Vladislav Zavialov <vladislav at serokell.io>
wrote:

> To put my 2¢ – I will be happy with whatever service provides the most
> reliable CI.
>
> In terms of workflow, I like Ben's suggestion:
>
>   * Consider a PR to be a stack of differentials, with each commit
> being an atomic change in that stack.
> _______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181101/4e8c9fdd/attachment.html>

From ben at smart-cactus.org  Fri Nov  2 00:42:32 2018
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 01 Nov 2018 20:42:32 -0400
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CAHYVw0yLt4xrQW5UZ05am1swE1Q7zvEEwmNaraLRv-JkcC1Hcw@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org>
 <87lg6f33my.fsf@smart-cactus.org>
 <CAJ0eudoCo68G_36QoBBpwaMMTLMZYQ=fFd3hPtvT64_Uh_ho_A@mail.gmail.com>
 <87y3af1g3n.fsf@smart-cactus.org>
 <CAJ0eudo=DXWoPgu0d=kj-2+y34ATM4e4G-+LWXgnpuqFuZ74Qg@mail.gmail.com>
 <CAEN7k7ngvbauDpkK_EUV+hs5V_82g9+yW7ttmuS-U8hPyNPFrg@mail.gmail.com>
 <87va5gzaeg.fsf@smart-cactus.org>
 <CAGL=qfHjasU7t27qJWVAcTePtE4j40588KzvDda5hCtANV=CPQ@mail.gmail.com>
 <CAHYVw0yLt4xrQW5UZ05am1swE1Q7zvEEwmNaraLRv-JkcC1Hcw@mail.gmail.com>
Message-ID: <87muqsz4wc.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> For what it’s worth, I’ve never found phab / arc to be the bottle neck /
> actual time consuming piece of doing anything for ghc
>
> It’s defintely the nicest code review substrate I’ve engaged with
>
> One question I have : how does the llvm org manage / handle their
> phabricator instance and or ci substrate. Maybe they have wisdom that can
> help ?
>
LLVM uses Jenkins primarily for CI; it is not integrated with their
Phabricator instance.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181101/fd52e2c9/attachment.sig>

From imantc at gmail.com  Fri Nov  2 08:24:03 2018
From: imantc at gmail.com (Imants Cekusins)
Date: Fri, 2 Nov 2018 09:24:03 +0100
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CANsrgPJDBx8ysVQm--y0SFaes82T7E1-VGcvieR0zjLXQuSnMA@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <87tvl31bps.fsf@smart-cactus.org>
 <CANsrgPJDBx8ysVQm--y0SFaes82T7E1-VGcvieR0zjLXQuSnMA@mail.gmail.com>
Message-ID: <CAP1qinbzVhua2s4J+9=sTfj7JmpjLPGugd14EAjYwBZtLOOwdg@mail.gmail.com>

Are other alternatives being considered?

You may find these examples relevant:

TFS
https://visualstudio.microsoft.com/tfs/   (Git repos is an option)

Atlassian
https://www.atlassian.com/
Atlassian offers rich set of integrated products.
https://www.atlassian.com/software/views/open-source-license-request
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181102/4673f9b0/attachment.html>

From ben at smart-cactus.org  Fri Nov  2 14:01:16 2018
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 02 Nov 2018 10:01:16 -0400
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CAP1qinbzVhua2s4J+9=sTfj7JmpjLPGugd14EAjYwBZtLOOwdg@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <87tvl31bps.fsf@smart-cactus.org>
 <CANsrgPJDBx8ysVQm--y0SFaes82T7E1-VGcvieR0zjLXQuSnMA@mail.gmail.com>
 <CAP1qinbzVhua2s4J+9=sTfj7JmpjLPGugd14EAjYwBZtLOOwdg@mail.gmail.com>
Message-ID: <87tvkzy3x2.fsf@smart-cactus.org>

Imants Cekusins <imantc at gmail.com> writes:

> Are other alternatives being considered?
>
I generally focused on GitHub and GitLab as these are the two options
that are widely used in the open-source community and received the most
attention in our survey results.

> You may find these examples relevant:
>
> TFS
> https://visualstudio.microsoft.com/tfs/   (Git repos is an option)
>
It seems the server requires a Windows machine to run. I consider this
to be an immediate dealbreaker.

> Atlassian
> https://www.atlassian.com/

I have worked with Atlassian products in the past and have not
found them to be convenient to use. Furthermore, neither of these
options are open source, which raises some serious lock-in concerns.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181102/c2b55a36/attachment.sig>

From chak at justtesting.org  Sun Nov  4 15:27:37 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sun, 4 Nov 2018 16:27:37 +0100
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
Message-ID: <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>

> Am 30.10.2018 um 10:07 schrieb Simon Marlow <marlowsd at gmail.com>:
> 
> 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?

FWIW, while I still think GitHub is preferable, GitLab would be an improvement over Phabricator IMHO.

Cheers,
Manuel


From carter.schonwald at gmail.com  Sun Nov  4 16:08:35 2018
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 4 Nov 2018 11:08:35 -0500
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>
Message-ID: <CAHYVw0z0c9ofn+jHwPTr5vDJ32rULtm30315BjCy8=vudAT5pQ@mail.gmail.com>

I’ve found that GitHub encourages git commits as a project journal even
though gits originating prject has a very diff / change set oriented
workflow.  And The latter is a more useful granularity of contribution for
complex prjects like ghc.

On Sun, Nov 4, 2018 at 10:27 AM Manuel M T Chakravarty <chak at justtesting.org>
wrote:

> > Am 30.10.2018 um 10:07 schrieb Simon Marlow <marlowsd at gmail.com>:
> >
> > 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?
>
> FWIW, while I still think GitHub is preferable, GitLab would be an
> improvement over Phabricator IMHO.
>
> Cheers,
> Manuel
>
> _______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181104/c82af6bc/attachment.html>

From m at tweag.io  Mon Nov  5 11:30:12 2018
From: m at tweag.io (Boespflug, Mathieu)
Date: Mon, 5 Nov 2018 12:30:12 +0100
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>
Message-ID: <CAJ0eudozqT_3Ut+6d+VHOQpbBGCxFev_J0j5uVQujTTkoqr-+w@mail.gmail.com>

So IIUC Gitlab features:

- Good multi-platform *hosted* CI or at least workable integration
with other (existing) CI solutions
- Hosted review tool that we don't have to maintain ourselves (though
a little bit less good than Phabricator, allegedly)
- familiar GitHub-like workflow with no requirement to install extra
software locally
- Reuse of GitHub credentials
- Realistic path forward for migrating tickets from Trac

This combination sounds pretty good to me!

Best,

--
Mathieu Boespflug
Founder at http://tweag.io.

On Sun, 4 Nov 2018 at 16:27, Manuel M T Chakravarty
<chak at justtesting.org> wrote:
>
> > Am 30.10.2018 um 10:07 schrieb Simon Marlow <marlowsd at gmail.com>:
> >
> > 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?
>
> FWIW, while I still think GitHub is preferable, GitLab would be an improvement over Phabricator IMHO.
>
> Cheers,
> Manuel
>
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group

From manuel.chakravarty at tweag.io  Tue Nov  6 10:30:13 2018
From: manuel.chakravarty at tweag.io (Manuel Chakravarty)
Date: Tue, 6 Nov 2018 11:30:13 +0100
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <CAJ0eudozqT_3Ut+6d+VHOQpbBGCxFev_J0j5uVQujTTkoqr-+w@mail.gmail.com>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>
 <CAJ0eudozqT_3Ut+6d+VHOQpbBGCxFev_J0j5uVQujTTkoqr-+w@mail.gmail.com>
Message-ID: <EDE3038D-C401-4A66-A58B-AD8F116AC43D@tweag.io>

Hi Ben,

With my DevOps Group Chair hat on, it seems that GitLab (as proposed by you) provides a suitable road forward (both in technical terms and in terms of being a compromise that most people are reasonably happy with). So, let’s do it!

Could you please make a list of all the tasks that need to be done and attach approximate effort/timelines where possible? (Maybe as a wiki page?)

Cheers,
Manuel

> Am 05.11.2018 um 12:30 schrieb Boespflug, Mathieu <m at tweag.io>:
> 
> So IIUC Gitlab features:
> 
> - Good multi-platform *hosted* CI or at least workable integration
> with other (existing) CI solutions
> - Hosted review tool that we don't have to maintain ourselves (though
> a little bit less good than Phabricator, allegedly)
> - familiar GitHub-like workflow with no requirement to install extra
> software locally
> - Reuse of GitHub credentials
> - Realistic path forward for migrating tickets from Trac
> 
> This combination sounds pretty good to me!
> 
> Best,
> 
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
> 
> On Sun, 4 Nov 2018 at 16:27, Manuel M T Chakravarty
> <chak at justtesting.org> wrote:
>> 
>>> Am 30.10.2018 um 10:07 schrieb Simon Marlow <marlowsd at gmail.com>:
>>> 
>>> 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?
>> 
>> FWIW, while I still think GitHub is preferable, GitLab would be an improvement over Phabricator IMHO.
>> 
>> Cheers,
>> Manuel
>> 
>> _______________________________________________
>> Ghc-devops-group mailing list
>> Ghc-devops-group at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group


From ben at well-typed.com  Tue Nov  6 17:05:19 2018
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 06 Nov 2018 12:05:19 -0500
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <EDE3038D-C401-4A66-A58B-AD8F116AC43D@tweag.io>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>
 <CAJ0eudozqT_3Ut+6d+VHOQpbBGCxFev_J0j5uVQujTTkoqr-+w@mail.gmail.com>
 <EDE3038D-C401-4A66-A58B-AD8F116AC43D@tweag.io>
Message-ID: <87in1auofo.fsf@smart-cactus.org>

Manuel Chakravarty <manuel.chakravarty at tweag.io> writes:

> Hi Ben,
>
> With my DevOps Group Chair hat on, it seems that GitLab (as proposed
> by you) provides a suitable road forward (both in technical terms and
> in terms of being a compromise that most people are reasonably happy
> with). So, let’s do it!
>
Yes, I agree!

> Could you please make a list of all the tasks that need to be done and
> attach approximate effort/timelines where possible? (Maybe as a wiki
> page?)
>
Yes, I have started a Wiki page here [1].

On the whole, I would like to proceed fairly quickly. For one, CI is
currently unacceptably flaky. Secondly, I would like to be able to
avoid having to start paying for our Rackspace boxes when support ends
at the end of the year.

However, there is then the question of scope. In principle, GitLab can
supplant three distinct services pretty well:

 a. Phabricator for code review
 b. gitolite, for repository hosting
 c. Trac, for issue tracking and the Wiki
 d. What remains of the Harbormaster CI

This discussion so far has largely focused on (a). I discuss the
remaining items in some depth on the wiki page.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/GitLabMigration?action=edit
[2] https://github.com/gitlabhq/gitlabhq/blob/667c0a909bde1cf71f21d8ec9768e98b1c489030/doc/hooks/custom_hooks.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181106/b0cceda5/attachment.sig>

From manuel.chakravarty at tweag.io  Wed Nov  7 09:48:24 2018
From: manuel.chakravarty at tweag.io (Manuel Chakravarty)
Date: Wed, 7 Nov 2018 10:48:24 +0100
Subject: [GHC DevOps Group] The future of Phabricator
In-Reply-To: <87in1auofo.fsf@smart-cactus.org>
References: <87zhuw2fw2.fsf@smart-cactus.org>
 <CANsrgPKfFDy0xpMX6Uy+vfXzPYNDtRtvWLnwFtLeX9dGShZQxw@mail.gmail.com>
 <F3BCE9CD-FA0E-4527-AFE4-D9C7AB74C391@justtesting.org>
 <CAJ0eudozqT_3Ut+6d+VHOQpbBGCxFev_J0j5uVQujTTkoqr-+w@mail.gmail.com>
 <EDE3038D-C401-4A66-A58B-AD8F116AC43D@tweag.io>
 <87in1auofo.fsf@smart-cactus.org>
Message-ID: <ADD1F4DB-139B-45F3-95FB-572BE3BF664A@tweag.io>

That all sounds very good to me.

If I understand correctly, the most tricky issue is the combination of 

(a) migrating Trac is not quite sorted yet and might require manual intervention and

(b) it really is much safer/easier to migrate Trac before switching git hosting over to GitLab.

Everything else can be sorted out incrementally. Is that right? 

You are writing that the goal is to accept MRs in a bit more than a months time (which is just in time before Rackspace goes away). Given that handling Trac seems to be the most volatile variable here, 

* what do you think when the migration script will be robust enough?
* how much of the remaining 90% can be done after migration by cleaning up migrated data?

Cheers,
Manuel

> Am 06.11.2018 um 18:05 schrieb Ben Gamari <ben at well-typed.com>:
> 
> Manuel Chakravarty <manuel.chakravarty at tweag.io> writes:
> 
>> Hi Ben,
>> 
>> With my DevOps Group Chair hat on, it seems that GitLab (as proposed
>> by you) provides a suitable road forward (both in technical terms and
>> in terms of being a compromise that most people are reasonably happy
>> with). So, let’s do it!
>> 
> Yes, I agree!
> 
>> Could you please make a list of all the tasks that need to be done and
>> attach approximate effort/timelines where possible? (Maybe as a wiki
>> page?)
>> 
> Yes, I have started a Wiki page here [1].
> 
> On the whole, I would like to proceed fairly quickly. For one, CI is
> currently unacceptably flaky. Secondly, I would like to be able to
> avoid having to start paying for our Rackspace boxes when support ends
> at the end of the year.
> 
> However, there is then the question of scope. In principle, GitLab can
> supplant three distinct services pretty well:
> 
> a. Phabricator for code review
> b. gitolite, for repository hosting
> c. Trac, for issue tracking and the Wiki
> d. What remains of the Harbormaster CI
> 
> This discussion so far has largely focused on (a). I discuss the
> remaining items in some depth on the wiki page.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://ghc.haskell.org/trac/ghc/wiki/GitLabMigration?action=edit
> [2] https://github.com/gitlabhq/gitlabhq/blob/667c0a909bde1cf71f21d8ec9768e98b1c489030/doc/hooks/custom_hooks.md