<div dir="ltr"><div><div>> (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.)<br><br></div>yes, a github PR is just a branch. Thanks for bringing the discussion back on track to a productive approach.<br></div>This suggestion is what some of us were getting at and it would be better to just limit the discussion to this idea.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 6:47 AM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am very much at the ignorant end of this debate: I'll just use whatever I'm told to use. But I do resonate with this observation from Austin:<br>
<span class=""><br>
| For one, having two code review tools of any form is completely<br>
| bonkers, TBQH. This is my biggest 'obvious' blocker. If we're going to<br>
| switch, we should just switch. Having to have people decide how to<br>
| contribute with two tools is as crazy as having two VCSs and just a<br>
| way of asking people to get *more* confused, and have us answer more<br>
| questions. That's something we need to avoid.<br>
<br>
</span>As a code contributor and reviewer, this is awkward. As a contributor, how do I choose? As a reviewer I'm presumably forced to learn both tools.<br>
<br>
But I'll go with the flow... I do not have a well-informed opinion about the tradeoffs.<br>
<br>
(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.)<br>
<span class="HOEnZb"><font color="#888888"><br>
Simon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
| -----Original Message-----<br>
| From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a>] On Behalf Of<br>
| Austin Seipp<br>
| Sent: 03 September 2015 05:42<br>
| To: Niklas Hambüchen<br>
| Cc: Simon Marlow; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
| Subject: Re: Proposal: accept pull requests on GitHub<br>
|<br>
| (JFYI: I hate to announce my return with a giant novel of negative-<br>
| nancy-ness about a proposal that just came up. I'm sorry about this!)<br>
|<br>
| TL;DR: I'm strongly -1 on this, because I think it introduces a lot of<br>
| associated costs for everyone, the benefits aren't really clear, and I<br>
| think it obscures the real core issue about "how do we get more<br>
| contributors" and how to make that happen. Needless to say, GitHub<br>
| does not magically solve both of these AFAICS.<br>
|<br>
| As is probably already widely known, I'm fairly against GitHub because<br>
| I think at best its tools are mediocre and inappropriate for GHC - but<br>
| I also don't think this proposal or the alternatives stemming from it<br>
| are very good, and that it reduces visibility of the real, core<br>
| complaints about what is wrong. Some of those problems may be with<br>
| Phabricator, but it's hard to sort the wheat from the chaff, so to<br>
| speak.<br>
|<br>
| For one, having two code review tools of any form is completely<br>
| bonkers, TBQH. This is my biggest 'obvious' blocker. If we're going to<br>
| switch, we should just switch. Having to have people decide how to<br>
| contribute with two tools is as crazy as having two VCSs and just a<br>
| way of asking people to get *more* confused, and have us answer more<br>
| questions. That's something we need to avoid.<br>
|<br>
| For the same reason, I'm also not a fan of 'use third party thing to<br>
| augment other thing to remove its deficiencies making it OK', because<br>
| the problem is _it adds surface area_ and other problems in other<br>
| cases. It is a solution that should be considered a last resort,<br>
| because it is a logical solution that applies to everything. If we<br>
| have a bot that moves GH PRs into Phab and then review them there, the<br>
| surface area of what we have to maintain and explain has suddenly<br>
| exploded: because now instead of 1 thing we have 3 things (GH, Phab,<br>
| bot) and the 3 interactions between them, for a multiplier of *six*<br>
| things we have to deal with. And then we use reviewable,io, because GH<br>
| reviews are terrible, adding a 4th mechanism? It's rube goldberg-ian.<br>
| We can logically 'automate' everything in all ways to make all<br>
| contributors happy, but there's a real *cognitive* overhead to this<br>
| and humans don't scale as well as computers do. It is not truly<br>
| 'automated away' if the cognitive burden is still there.<br>
|<br>
| I also find it extremely strange to tell people "By the way, this<br>
| method in which you've contributed, as was requested by community<br>
| members, is actually a complete proxy for the real method of<br>
| contributing, you can find all your imported code here". How is this<br>
| supposed to make contribution *easier* as opposed to just more<br>
| confusing? Now you've got the impression you're using "the real thing"<br>
| when in reality it's shoved off somewhere else to have the nitpicking<br>
| done. Just using Phabricator would be less complicated, IMO, and much<br>
| more direct.<br>
|<br>
| The same thing goes for <a href="http://reviewable.io" rel="noreferrer" target="_blank">reviewable.io</a>. Adding it as a layer over<br>
| GitHub just makes the surface area larger, and puts less under our<br>
| control. And is it going to exist in the same form in 2 or 3 years?<br>
| Will it continue to offer the same tools, the same workflows that we<br>
| "like", and what happens when we hit a wall? It's easy to say<br>
| "probably" or "sure" to all this, until we hit something we dislike<br>
| and have no possibility of fixing.<br>
|<br>
| And once you do all this, BTW, you can 'never go back'. It seems so<br>
| easy to just say 'submit pull requests' once and nothing else, right?<br>
| Wrong. Once you commit to that infrastructure, it is *there* and<br>
| simply taking it out from under the feet of those using it is not only<br>
| unfortunate, it is *a huge timesink to undo it all*. Which amounts to<br>
| it never happening. Oh, but you can import everything elsewhere! The<br>
| problem is you *can't* import everything, but more importantly you<br>
| can't *import my memories in another way*, so it's a huge blow to<br>
| contributors to ask them about these mental time sinks, then to forget<br>
| them all. And as your project grows, this becomes more of a memory as<br>
| you made a first and last choice to begin with.<br>
|<br>
| Phabricator was 'lucky' here because it had the gateway into being the<br>
| first review tool for us. But that wasn't because it was *better* than<br>
| GitHub. It was because we were already using it, and it did not<br>
| interact badly with our other tools or force us to compromise things -<br>
| so the *cost* was low. The cost is immeasurably higher by default<br>
| against GitHub because of this, at least to me. That's just how it is<br>
| sometimes.<br>
|<br>
| Keep in mind there is a cost to everything and how you fix it. GitHub<br>
| is not a simple patch to add a GHC feature. It is a question that<br>
| fundamentally concerns itself with the future of the project for a<br>
| long time. The costs must be analyzed more aggressively. Again,<br>
| Phabricator had 'first child' preferential treatment. That's not<br>
| something we can undo now.<br>
|<br>
| I know this sounds like a lot of ad hoc mumbo jumbo, but please bear<br>
| with me: we need to identify the *root issue* here to fix it.<br>
| Otherwise we will pay for the costs of an improper fix for a long<br>
| time, and we are going to keep having this conversation over, and over<br>
| again. And we need to weigh in the cost of fixing it, which is why I<br>
| mention that so much.<br>
|<br>
| So with all this in mind, you're back to just using GitHub. But again<br>
| GitHub is quite mediocre at best. So what is the point of all this?<br>
| It's hinted at here:<br>
|<br>
| > the number of contributions will go up, commits will be smaller, and<br>
| there will be more of them per pull request (contributors will be able<br>
| to put style changes and refactorings into separate commits, without<br>
| jumping through a bunch of hoops).<br>
|<br>
| The real hint is that "the number of contributions will go up". That's<br>
| a noble goal and I think it's at the heart of this proposal.<br>
|<br>
| Here's the meat of it question: what is the cost of achieving this<br>
| goal? That is, what amount of work is sufficient to make this goal<br>
| realizable, and finally - why is GitHub *the best use of our time for<br>
| achieving this?* That's one aspect of the cost - that it's the best<br>
| use of the time. I feel like this is fundamentally why I always seem<br>
| to never 'get' this argument, and I'm sure it's very frustrating on<br>
| behalf of the people who have talked to me about it and like GitHub.<br>
| But I feel like I've never gotten a straight answer for GHC.<br>
|<br>
| If the goal is actually "make more people contribute", that's pretty<br>
| broad. I can make that very easy: give everyone who ever submits a<br>
| patch push access. This is a legitimate way to run large projects that<br>
| has worked. People will almost certainly be more willing to commit,<br>
| especially when overhead on patch submission is reduced so much. Why<br>
| not just do that instead? It's not like we even mandate code review,<br>
| although we could. You could reasonably trust CI to catch and revert<br>
| things a lot of the time for people who commit directly to master. We<br>
| all do it sometimes.<br>
|<br>
| I'm being serious about this. I can start doing that tomorrow because<br>
| the *cost is low*, both now and reasonably speaking into some<br>
| foreseeable future. It is one of many solutions to raw heart of the<br>
| proposal. GitHub is not a low cost move, but also, it is a *long term<br>
| cost* because of the technical deficiencies it won't aim to address<br>
| (merge commits are ugly, branch reviews are weak, ticket/PR namespace<br>
| overlaps with Trac, etc etc) or that we'll have to work around.<br>
|<br>
| That means that if we want GitHub to fix the "give us more<br>
| contributors" problem, and it has a high cost, it not only has _to fix<br>
| the problem_, it also has to do that well enough to offset its cost. I<br>
| don't think it's clear that is the case right now, among a lot of<br>
| other solutions.<br>
|<br>
| I don't think the root issue is "We _need_ GitHub to get more<br>
| contributors". It sounds like the complaint is more "I don't like how<br>
| Phabricator works right now". That's an important distinction, because<br>
| the latter is not only more specific, it's more actionable:<br>
|<br>
| - Things like Arcanist can be tracked as a Git submodule. There is<br>
| little to no pain in this, it's low cost, and it can always be<br>
| synchronized with Phabricator. This eliminates the "Must clone<br>
| arcanist" and "need to upgrade arcanist" points.<br>
|<br>
| - Similarly when Phabricator sometimes kills a lot of builds, it's<br>
| because I do an upgrade. That's mostly an error on my part and I can<br>
| simply schedule upgrades regularly, barring hotfixes or somesuch. That<br>
| should basically eliminate these. The other build issues are from<br>
| picking the wrong base commit from the revision, I think, which I<br>
| believe should be fixable upstream (I need to get a solid example of<br>
| one that isn't a mega ultra patch.)<br>
|<br>
| - If Harbormaster is not building dependent patches as mentioned in<br>
| WhyNotPhabricator, that is a bug, and I have not been aware of it.<br>
| Please make me aware of it so I can file bugs! I seriously don't look<br>
| at _every_ patch, I need to know this. That could have probably been<br>
| fixed ASAP otherwise.<br>
|<br>
| - We can get rid of the awkwardness of squashes etc by using<br>
| Phabricator's "immutable" history, although it introduces merge<br>
| commits. Whether this is acceptable is up to debate (I dislike merge<br>
| commits, but could live with it).<br>
|<br>
| - I do not understand point #3, about answering questions. Here's<br>
| the reality: every single one of those cases is *almost always an<br>
| error*. That's not a joke. Forgetting to commit a file, amending<br>
| changes in the working tree, and specifying a reviewer are all total<br>
| errors as it stands today. Why is this a minus? It catches a useful<br>
| class of 'interaction bugs'. If it's because sometimes Phabricator<br>
| yells about build arifacts in the tree, those should be .gitignore'd.<br>
| If it's because you have to 'git stash' sometimes, this is fairly<br>
| trivial IMO. Finally, specifying reviewers IS inconvenient, but<br>
| currently needed. We could easily assign a '#reviewers' tag that would<br>
| add default reviewers.<br>
| - In the future, Phabricator will hopefully be able to<br>
| automatically assign the right reviewers to every single incoming<br>
| patch, based on the source file paths in the tree, using the Owners<br>
| tool. Technically, we could do that today if we wanted, it's just a<br>
| little more effort to add more Herald rules. This will be far, far<br>
| more robust than anything GitHub can offer, and eliminates point #3.<br>
|<br>
| - Styling, linting etc errors being included, because reviews are<br>
| hard to create: This is tangential IMO. We need to just bite the<br>
| bullet on this and settle on some lint and coding styles, and apply<br>
| them to the tree uniformly. The reality is *nobody ever does style<br>
| changes on their own*, and they are always accompanied by a diff, and<br>
| they always have to redo the work of pulling them out, Phab or not.<br>
| Literally 99% of the time we ask for this, it happens this way.<br>
| Perhaps instead we should just eliminate this class of work by just<br>
| running linters over all of the source code at once, and being happy<br>
| with it.<br>
|<br>
| Doing this in fact has other benefits: like `arc lint` will always<br>
| _correctly_ report when linting errors are violated. And we can reject<br>
| patches that violate them, because they will always be accurate.<br>
|<br>
| - As for some of the quotes, some of them are funny, but the real<br>
| message lies in the context. :) In particular, there have been several<br>
| cases (such as the DWARF work) where the idea was "write 30 commits<br>
| and put them on Phabricator". News flash: *this is bad*, no matter<br>
| whether you're using Phabricator or not, because it makes reviewing<br>
| the whole thing immensely difficult from a reviewer perspective. The<br>
| point here is that we can clear this up by being more communicative<br>
| about what we expect of authors of large patches, and communicating<br>
| your intent ASAP so we can get patches in as fast as possible. Writing<br>
| a patch is the easiest part of the work.<br>
|<br>
| And more:<br>
|<br>
| - Clean up the documentation, it's a mess. It feels nice that<br>
| everything has clear, lucid explanations on the wiki, but the wiki is<br>
| ridiculously massive and we have a tendancy for 'link creep' where we<br>
| spread things out. The contributors docs could probably stand to be<br>
| streamlined. We would have to do this anyway, moving to GitHub or not.<br>
|<br>
| - Improve the homepage, directly linking to this aforementioned<br>
| page.<br>
|<br>
| - Make it clear what we expect of contributors. I feel like a lot of<br>
| this could be explained by having a 5 minute drive-by guide for<br>
| patches, and then a longer 10-minute guide about A) How to style<br>
| things, B) How to format your patches if you're going to contribute<br>
| regularly, C) Why it is this way, and D) finally links to all the<br>
| other things you need to know. People going into Phabricator expecting<br>
| it to behave like GitHub is a problem (more a cultural problem IMO but<br>
| that's another story), and if this can't be directly fixed, the best<br>
| thing to do is make it clear why it isn't.<br>
|<br>
| Those are just some of the things OTTOMH, but this email is already<br>
| way too long. This is what I mean though: fixing most of these is<br>
| going to have *seriously smaller cost* than moving to GitHub. It does<br>
| not account for "The GitHub factor" of people contributing "just<br>
| because it's on GitHub", but again, that value has to outweigh the<br>
| other costs. I'm not seriously convinced it does.<br>
|<br>
| I know it's work to fix these things. But GitHub doesn't really<br>
| magically make a lot of our needs go away, and it's not going to<br>
| magically fix things like style or lint errors, the fact Travis-CI is<br>
| still pretty insufficient for us in the long term (and Harbormaster is<br>
| faster, on our own hardware, too), or that it will cause needlessly<br>
| higher amounts of spam through Trac and GitHub itself. I don't think<br>
| settling on it as - what seems to be - a first resort, is a really<br>
| good idea.<br>
|<br>
|<br>
| On Wed, Sep 2, 2015 at 4:09 PM, Niklas Hambüchen <<a href="mailto:mail@nh2.me">mail@nh2.me</a>> wrote:<br>
| > On 02/09/15 22:42, Kosyrev Serge wrote:<br>
| >> As a wild idea -- did anyone look at /Gitlab/ instead?<br>
| ><br>
| > Hi, yes. It does not currently have a sufficient review<br>
| functionality<br>
| > (cannot handle multiple revisions easily).<br>
| ><br>
| > On 02/09/15 20:51, Simon Marlow wrote:<br>
| >> It might feel better<br>
| >> for the author, but discovering what changed between two branches<br>
| of<br>
| >> multiple commits on github is almost impossible.<br>
| ><br>
| > I disagree with the first part of this: When the UI of the review<br>
| tool<br>
| > is good, it is easy to follow. But there's no open-source<br>
| > implementation of that around.<br>
| ><br>
| > I agree that it is not easy to follow on Github.<br>
| > _______________________________________________<br>
| > ghc-devs mailing list<br>
| > <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
| > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
| ><br>
|<br>
|<br>
|<br>
| --<br>
| Regards,<br>
|<br>
| Austin Seipp, Haskell Consultant<br>
| Well-Typed LLP, <a href="http://www.well-typed.com/" rel="noreferrer" target="_blank">http://www.well-typed.com/</a><br>
| _______________________________________________<br>
| ghc-devs mailing list<br>
| <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
| <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>