Re: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Carter Schonwald  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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Carter Schonwald]

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 
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@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

Re: [GHC DevOps Group] The future of Phabricator

[Vladislav Zavialov]

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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Michal Terepeta  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



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

"Boespflug, Mathieu"  writes:

> Hi Ben,
>
> On Tue, 30 Oct 2018 at 18:47, Ben Gamari  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



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Hadrian build failed

[Andrey Mokhov]

Hello Yotam,

Could you please report this as a bug on GHC Trac?

https://ghc.haskell.org/trac/ghc/wiki/ReportABug

I couldn’t quickly reproduce your issue, however, I run into another seemingly 
unrelated problem.

P.S.: Note that build instructions in my blog post got slightly out of date 
after the Hadrian move – I’ve fixed this.

Cheers,
Andrey

 Forwarded Message 
Subject:

Hadrian build failed

Date:

Thu, 1 Nov 2018 20:33:14 +0200

From:

Yotam Ohad 

To:

ghc-devs@haskell.org


Hi,
I'm trying to build with hadrian 
(https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/)
I get an error when running: stack exec hadrian -- --directory ".." -j 
--flavour=quickest --configure

md5sum: 'standard input': no properly formatted MD5 checksum lines found

ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to 
be corrupted, please delete it and try again.
)
Deleting and trying again results in the same error. Any idea on how to solve 
this?

Yotam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hadrian build failed

[Yotam Ohad]

Hi,
I'm trying to build with hadrian (
https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/)
I get an error when running: stack exec hadrian -- --directory ".." -j
--flavour=quickest --configure

md5sum: 'standard input': no properly formatted MD5 checksum lines found

ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz
appears to be corrupted, please delete it and try again.
)
Deleting and trying again results in the same error. Any idea on how to
solve this?

Yotam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Michal Terepeta]

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  wrote:

> 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.
> ___
> 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

Re: Validating with LLVM

[Ben Gamari]

Travis Whitaker  writes:

> Hello GHC Devs,
>
> I'm working on a very tiny patch for GHC. The patch concerns the LLVM code
> generator, and I'd like to run the validate script. ./validate ignores mk/
> build.mk (which is probably correct) and it doesn't seem to be using the
> LLVM backend. LLVM tools are on the PATH; I'm working from the ghc-8.4
> branch so I'm using LLVM 5.
>
> Is it possible to validate with the LLVM backend? If not, what's considered
> a sufficiently thorough test? Apologies if I'm missing something obvious.
>
The validate script doesn't support this directly. I would do the
following:

./validate --build-only
make test WAY=llvm

That should do what you want (and IIRC is what we do in the LLVM CI
script).

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs