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 kinda makes stuff even more confusing than Git by itself"). Newcomers will give it their best shot, thinking it's just another thing they need to learn, thinking it's their fault for running into problems, thinking they'll get the hang of it eventually. Except they won't, or at least I haven't, after using it for over a year. Maybe the fundamental problem with Phabricator is that it doesn't understand Git well, and the problems I posted on https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator are just symptoms of it. I'm having trouble putting this into words though (something about branches and submodules). Perhaps someone else can? In my opinion it's is a waste of our time trying to improve `arc` (it is 34000 lines of PHP btw + another 70000 LOC for libphutil), when `pull requests` are an obvious alternative that most of the Haskell community already uses. When you're going to require contributors to use a non-standard tool to get patches to your code review system, it better just work. `arc` is clearly failing us here, and I'm saying enough is enough. I need to think about your other points. Thank you for the thorough reply.

Here's the meat of it question: what is the cost of achieving this goal? That is, what amount of work is sufficient to make this goal realizable, and finally - why is GitHub *the best use of our time for achieving this?* That's one aspect of the cost - that it's the best use of the time. I feel like this is fundamentally why I always seem to never 'get' this argument, and I'm sure it's very frustrating on behalf of the people who have talked to me about it and like GitHub. But I feel like I've never gotten a straight answer for GHC.

If the goal is actually "make more people contribute", that's pretty broad. I can make that very easy: give everyone who ever submits a patch push access. This is a legitimate way to run large projects that has worked. People will almost certainly be more willing to commit, especially when overhead on patch submission is reduced so much. Why not just do that instead? It's not like we even mandate code review, although we could. You could reasonably trust CI to catch and revert things a lot of the time for people who commit directly to master. We all do it sometimes.

I'm being serious about this. I can start doing that tomorrow because the *cost is low*, both now and reasonably speaking into some foreseeable future. It is one of many solutions to raw heart of the proposal. GitHub is not a low cost move, but also, it is a *long term cost* because of the technical deficiencies it won't aim to address (merge commits are ugly, branch reviews are weak, ticket/PR namespace overlaps with Trac, etc etc) or that we'll have to work around.

That means that if we want GitHub to fix the "give us more contributors" problem, and it has a high cost, it not only has _to fix the problem_, it also has to do that well enough to offset its cost. I don't think it's clear that is the case right now, among a lot of other solutions.

I don't think the root issue is "We _need_ GitHub to get more contributors". It sounds like the complaint is more "I don't like how Phabricator works right now". That's an important distinction, because the latter is not only more specific, it's more actionable:

- Things like Arcanist can be tracked as a Git submodule. There is little to no pain in this, it's low cost, and it can always be synchronized with Phabricator. This eliminates the "Must clone arcanist" and "need to upgrade arcanist" points.

- Similarly when Phabricator sometimes kills a lot of builds, it's because I do an upgrade. That's mostly an error on my part and I can simply schedule upgrades regularly, barring hotfixes or somesuch. That should basically eliminate these. The other build issues are from picking the wrong base commit from the revision, I think, which I believe should be fixable upstream (I need to get a solid example of one that isn't a mega ultra patch.)

- If Harbormaster is not building dependent patches as mentioned in WhyNotPhabricator, that is a bug, and I have not been aware of it. Please make me aware of it so I can file bugs! I seriously don't look at _every_ patch, I need to know this. That could have probably been fixed ASAP otherwise.

- We can get rid of the awkwardness of squashes etc by using Phabricator's "immutable" history, although it introduces merge commits. Whether this is acceptable is up to debate (I dislike merge commits, but could live with it).

- I do not understand point #3, about answering questions. Here's the reality: every single one of those cases is *almost always an error*. That's not a joke. Forgetting to commit a file, amending changes in the working tree, and specifying a reviewer are all total errors as it stands today. Why is this a minus? It catches a useful class of 'interaction bugs'. If it's because sometimes Phabricator yells about build arifacts in the tree, those should be .gitignore'd. If it's because you have to 'git stash' sometimes, this is fairly trivial IMO. Finally, specifying reviewers IS inconvenient, but currently needed. We could easily assign a '#reviewers' tag that would add default reviewers. - In the future, Phabricator will hopefully be able to automatically assign the right reviewers to every single incoming patch, based on the source file paths in the tree, using the Owners tool. Technically, we could do that today if we wanted, it's just a little more effort to add more Herald rules. This will be far, far more robust than anything GitHub can offer, and eliminates point #3.

- Styling, linting etc errors being included, because reviews are hard to create: This is tangential IMO. We need to just bite the bullet on this and settle on some lint and coding styles, and apply them to the tree uniformly. The reality is *nobody ever does style changes on their own*, and they are always accompanied by a diff, and they always have to redo the work of pulling them out, Phab or not. Literally 99% of the time we ask for this, it happens this way. Perhaps instead we should just eliminate this class of work by just running linters over all of the source code at once, and being happy with it.

Doing this in fact has other benefits: like `arc lint` will always _correctly_ report when linting errors are violated. And we can reject patches that violate them, because they will always be accurate.

- As for some of the quotes, some of them are funny, but the real message lies in the context. :) In particular, there have been several cases (such as the DWARF work) where the idea was "write 30 commits and put them on Phabricator". News flash: *this is bad*, no matter whether you're using Phabricator or not, because it makes reviewing the whole thing immensely difficult from a reviewer perspective. The point here is that we can clear this up by being more communicative about what we expect of authors of large patches, and communicating your intent ASAP so we can get patches in as fast as possible. Writing a patch is the easiest part of the work.

And more:

- Clean up the documentation, it's a mess. It feels nice that everything has clear, lucid explanations on the wiki, but the wiki is ridiculously massive and we have a tendancy for 'link creep' where we spread things out. The contributors docs could probably stand to be streamlined. We would have to do this anyway, moving to GitHub or not.

- Improve the homepage, directly linking to this aforementioned page.

- 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 if you're going to contribute regularly, C) Why it is this way, and D) finally links to all the other things you need to know. People going into Phabricator expecting it to behave like GitHub is a problem (more a cultural problem IMO but that's another story), and if this can't be directly fixed, the best thing to do is make it clear why it isn't.

Those are just some of the things OTTOMH, but this email is already way too long. This is what I mean though: fixing most of these is going to have *seriously smaller cost* than moving to GitHub. It does not account for "The GitHub factor" of people contributing "just because it's on GitHub", but again, that value has to outweigh the other costs. I'm not seriously convinced it does.

I know it's work to fix these things. But GitHub doesn't really magically make a lot of our needs go away, and it's not going to magically fix things like style or lint errors, the fact Travis-CI is still pretty insufficient for us in the long term (and Harbormaster is faster, on our own hardware, too), or that it will cause needlessly higher amounts of spam through Trac and GitHub itself. I don't think settling on it as - what seems to be - a first resort, is a really good idea.

On Wed, Sep 2, 2015 at 4:09 PM, Niklas Hambüchen wrote:

...

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 discovering what changed between two branches of multiple commits on github is almost impossible.

I disagree with the first part of this: When the UI of the review tool is good, it is easy to follow. But there's no open-source implementation of that around.

I agree that it is not easy to follow on Github. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs