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. A
u know not everybody out there is unhappy with phab. (-:
cheers,
m.
On Sun, Nov 01, 2015 at 06:11:23PM -0800, Simon Marlow wrote:
> Date: Sun, 1 Nov 2015 18:11:23 -0800
> From: Simon Marlow
> To: Nikita Karetnikov , Niklas Hambüchen
>
> Cc: "ghc-devs@haskell.org"
&
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 proce
Hello Nikita,
Phabricator has a model where you can make all of your comments in a
batch (unsubmitted), and then submit them at once. TBH, I've never
had a workflow where I didn't want my intermediate comments to be
posted immediately, but it also hasn't been too much of a bother
to make my comme
> 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 h
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 i
> > (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 bypasse
cket? Then we 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:
hen
| Cc: Simon Marlow; ghc-devs@haskell.org
| 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 thi
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 uses.
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 f
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 files.
Curiously, for t
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 associated costs for every
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
those contributions.
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 syst
>
> 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 k
> 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.
___
gh
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) How to format your patches
(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 t
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 dis
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 github's support for code
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 multiple commits on gith
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 github's support for code reviews is too weak to
recommend it
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 1:4
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 al
Hello all,
my arguments against Phabricator are here:
https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.
Some quotes from #ghc to pique your curiosity (there are some 50 more):
* "is arc broken today?"
* "arc is a frickin' mystery."
* "i have a theory that i've managed to create a revisi
26 matches
Mail list logo
