Re: Arcanist "lite" Haskell reimplementation (was: Proposal: accept pull requests on GitHub)

2015-11-20 Thread Tuncer Ayaz
On 6 September 2015 at 16:06, Herbert Valerio Riedel wrote: > I went ahead wasting some time and hacked up `arc-lite` for fun: > > https://github.com/haskell-infra/arc-lite > > It's currently at 407 Haskell SLOCs according to sloccount(1), and > emulates the `arc` CLI as a drop-in replacement.

Re: Proposal: accept pull requests on GitHub

2015-11-01 Thread Simon Marlow
On 28/10/2015 14:30, Nikita Karetnikov wrote: I would recommend against moving code reviews to Github. I like it and use it all the time for my own projects, but for a large project like GHC, its code reviews are too basic (comments get lost in multi-round reviews), and its customisation an

Re: Proposal: accept pull requests on GitHub

2015-10-28 Thread Nikita Karetnikov
> I would recommend against moving code reviews to Github. > I like it and use it all the time for my own projects, but for a large > project like GHC, its code reviews are too basic (comments get lost in > multi-round reviews), and its customisation an process enforcement is > too weak; but that

Re: Proposal: accept pull requests on GitHub

2015-09-09 Thread Richard Eisenberg
> > (I'm tempted naively to ask: is there an automated way to go from a GitHub > > PR to a Phab ticket? Then we could convert the former (if someone wants to > > submit that way) into the latter.) Or: is there a way contributors can create a Phab differential off a GitHub branch? This

Re: Proposal: accept pull requests on GitHub

2015-09-09 Thread Oleg Grenrus
As a junior ghc contributor, I have to comment that git push -u my-fork my-branch and arc diff are about of the same “cognitive load”. Yes, one must have arc on the machine, but if the right version could live as a submodule in GHC tree: even better. And a bit tangental comment: I can

Re: Proposal: accept pull requests on GitHub

2015-09-08 Thread Greg Weber
could convert the former (if someone wants to > submit that way) into the latter.) > > Simon > > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of > | Austin Seipp > | Sent: 03 September 2015 05:42 > | To: Niklas Hambüchen

RE: Proposal: accept pull requests on GitHub

2015-09-07 Thread Simon Peyton Jones
| Subject: Re: Proposal: accept pull requests on GitHub | | (JFYI: I hate to announce my return with a giant novel of negative- | nancy-ness about a proposal that just came up. I'm sorry about this!) | | TL;DR: I'm strongly -1 on this, because I think it introduces a lot of | associated

Arcanist "lite" Haskell reimplementation (was: Proposal: accept pull requests on GitHub)

2015-09-06 Thread Herbert Valerio Riedel
On 2015-09-03 at 11:53:40 +0200, Thomas Miedema wrote: [...] > In my opinion it's is a waste of our time trying to improve `arc` (it is > 34000 lines of PHP btw + another 7 LOC for libphutil), when `pull > requests` are an obvious alternative that most of the Haskell community > already

Re: Proposal: accept pull requests on GitHub

2015-09-03 Thread Joe Hillenbrand
> As a wild idea -- did anyone look at /Gitlab/ instead? My personal experience with Gitlab at a previous job is that it is extremely unstable. I'd say even more unstable than trac and phabricator. It's especially bad when dealing with long files. ___

Re: Proposal: accept pull requests on GitHub

2015-09-03 Thread Thomas Miedema
> > The real hint is that "the number of contributions will go up". That's > a noble goal and I think it's at the heart of this proposal. > It's not. What's at the heart of my proposal is that `arc` sucks. Most of those quotes I posted are from regular contributors (here's another one: "arcanist

Re: Proposal: accept pull requests on GitHub

2015-09-03 Thread Vincent Hanquez
On 03/09/2015 10:53, Thomas Miedema wrote: The real hint is that "the number of contributions will go up". That's a noble goal and I think it's at the heart of this proposal. When you're going to require contributors to use a non-standard tool to get patches to your code review

Re: Proposal: accept pull requests on GitHub

2015-09-03 Thread Thomas Miedema
On Thu, Sep 3, 2015 at 12:43 PM, Vincent Hanquez wrote: > there's (probably) lots of small/janitorial contributions that do not need > the full power of phabricator or any sophisticated code review. > Austin's point, and I agree, is that we shouldn't optimize the system for

Re: UNS: Re: Proposal: accept pull requests on GitHub

2015-09-03 Thread Kosyrev Serge
Joe Hillenbrand writes: >> As a wild idea -- did anyone look at /Gitlab/ instead? > > My personal experience with Gitlab at a previous job is that it is > extremely unstable. I'd say even more unstable than trac and > phabricator. It's especially bad when dealing with long

Re: Proposal: accept pull requests on GitHub

2015-09-03 Thread Tuncer Ayaz
On Thu, Sep 3, 2015 at 6:41 AM, Austin Seipp wrote: > (JFYI: I hate to announce my return with a giant novel of > negative-nancy-ness about a proposal that just came up. I'm sorry > about this!) > > TL;DR: I'm strongly -1 on this, because I think it introduces a lot > of

Re: Proposal: accept pull requests on GitHub

2015-09-03 Thread Bardur Arantsson
On 09/03/2015 09:18 AM, Joe Hillenbrand wrote: >> As a wild idea -- did anyone look at /Gitlab/ instead? > > My personal experience with Gitlab at a previous job is that it is > extremely unstable. I'd say even more unstable than trac and > phabricator. It's especially bad when dealing with long

Re: Proposal: accept pull requests on GitHub

2015-09-02 Thread Greg Weber
I like Niklas's suggestion of a middle-ground approach. There are benefits to using phabricator (and arc), but there should be a lowered-bar approach where people can start contributing through github (even though they may be forced to do the code review on phabricator). On Tue, Sep 1, 2015 at

Re: Proposal: accept pull requests on GitHub

2015-09-02 Thread Austin Seipp
(JFYI: I hate to announce my return with a giant novel of negative-nancy-ness about a proposal that just came up. I'm sorry about this!) TL;DR: I'm strongly -1 on this, because I think it introduces a lot of associated costs for everyone, the benefits aren't really clear, and I think it obscures

Re: Proposal: accept pull requests on GitHub

2015-09-02 Thread Michael Smith
On Wed, Sep 2, 2015 at 9:41 PM, Austin Seipp wrote: > - Make it clear what we expect of contributors. I feel like a lot of > this could be explained by having a 5 minute drive-by guide for > patches, and then a longer 10-minute guide about A) How to style > things, B)

Re: Proposal: accept pull requests on GitHub

2015-09-02 Thread Kosyrev Serge
Simon Marlow writes: > On 01/09/2015 11:34, Thomas Miedema wrote: >> Hello all, >> >> my arguments against Phabricator are here: >> https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator. > > Thanks for taking the time to summarize all the issues. > > Personally, I think

Re: Proposal: accept pull requests on GitHub

2015-09-02 Thread Tuncer Ayaz
On Wed, Sep 2, 2015 at 8:51 PM, Simon Marlow wrote: > Stacks of commits are hard to reviewers to follow, so making them > easier might have a detrimental effect on our processes. It might > feel better for the author, but discovering what changed between two > branches of

Re: Proposal: accept pull requests on GitHub

2015-09-02 Thread Niklas Hambüchen
On 02/09/15 22:42, Kosyrev Serge wrote: > As a wild idea -- did anyone look at /Gitlab/ instead? Hi, yes. It does not currently have a sufficient review functionality (cannot handle multiple revisions easily). On 02/09/15 20:51, Simon Marlow wrote: > It might feel better > for the author, but

Re: Proposal: accept pull requests on GitHub

2015-09-01 Thread Niklas Hambüchen
Hi, I would recommend against moving code reviews to Github. I like it and use it all the time for my own projects, but for a large project like GHC, its code reviews are too basic (comments get lost in multi-round reviews), and its customisation an process enforcement is too weak; but that has