Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

Carter Schonwald

25 Sep 2016 25 Sep '16

6:02 p.m.

In writing the following huge wall of text, I had and idea that I think many folks would find palatable: What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple! What's even nice about this is its future proof and even agnostic to how the contributor made the change set locally! They could use mercurial or fossil for all we care. Or github. Or whatever! My personal stance is that ghc already way easier to contribute to / get involved with than it was 2-5 years ago. This is even more impressive when you consider the number of contributors (who aren't students) that focus on ghc work full time has actually DECREASED over that period. Community engagement / management is a totally orthogonal skill from contributing. Both take effort. Guiding new contributors requires both. My personal stance is that ghc keeps on getting better and getting more contributors. And occasionally chatting about ways to make things better that we have the bandwidth to do is something that should happen every year or so. Like a health checkup. I suspect one funnel for improvement may be figuring out how to make it more visible how many contributors / how actively deved various subsystems are. I feel like many new folks veer towards subsystems that are already actively worked on, which are often the ones that are both the most mature and thus hardest to easily contribute to! Perhaps I should see if there's an easy way to quantify that in a way that's easy to communicate to new contributors. There's an interesting data presentation challenge in that! I've definitely found that for new potential contributors that orienting them to focus on subsystem that's important but doesn't get much activity leads to more successful first contributions. But that requires someone actively helping orient folks, which I like to think I've helped out with at points in recent years. Making this something that's easy to point at / discover along with "newcomer tickets" might help a lot Tweaking the way we do tickets or code review I think doesn't change the important / fundamental challenges of doing a good patch for a project like ghc or llvm. (I think in some ways that llvm / gcc / clang are the right size projects to compare ghc against ) On Saturday, September 24, 2016, Brandon Allbery wrote:

...

On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < chak@justtesting.org javascript:_e(%7B%7D,'cvml','chak@justtesting.org');> wrote:

...
Why are you so hostile to Chris? I don’t think that this is an appropriate way to treat somebody who is making a suggestion in good faith.

It may be in good faith. but it's not in good sense. There is a lot in the background that made Rust's setup possible, and he's not bringing that to the table, just assuming it'll somehow happen or that everyone else will drop everything for the next few months and make it happen. And I feel like he's being really pushy about committing already overworked people to this --- and insisting that anyone opposed must have a hidden agenda or otherwise cannot possibly have good reason to be opposed. It's not helpful at all; it's basically a good way to stall ghc for the next few months at least.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com javascript:_e(%7B%7D,'cvml','allbery.b@gmail.com'); ballbery@sinenomine.net javascript:_e(%7B%7D,'cvml','ballbery@sinenomine.net'); unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Attachments:

attachment.html (text/html — 4.7 KB)

Show replies by date

Michael Sloan

26 Sep 26 Sep

2:33 a.m.

I like this solution a lot, Carter! Mailing patches directly to the ghc-devs list could be intimidating for newcomers. Having a list specific to patch review could make the process less intimidating. From a perspective of overall contribution intimidation, these 2 pages make it seem like a ton of extra work to contribute to GHC: 1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs 2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures Of course, I understand that these exist for a reason. Contributing to GHC isn't easy, and it does need processes, and those processes should be followed! However, for documentation patches and minor fixes, these pages make it seem like you really have to put in quite a bit to get started, and that the process is bureaucratic. Atop getting accounts setup and figuring out how to get ghc compiled, the amount of time investment to get in a simple patch already seems like it is on the order of hours, if not a full days worth of work. At the risk of accumulating spam, perhaps the list shouldn't even require membership? Just have it filter based on containing an attachment (perhaps even require a "*.patch" attachment?) I also think that there should be an easy way to put a stop to iterating via email and sending .patch files, and escalate to a phabricator review. Perhaps this could be scripted? Is there any way for people to use phabricator without using archanist? Not a criticism of the tech, but it is more to learn, and foreign to most. One thing I've learned from maintaining stack, is that it can be really helpful to accept patches that are imperfect. Here's how this works: 1) Some user wants to fix something, and doesn't quite nail it. Maybe makes some style mistakes, spelling errors in comments, or perhaps writes some part of the code in a less direct way than possible 2) If the overall change is an improvement and the fixes are easy, I go ahead and merge the imperfect patch, and then commit my own fixes to the issues I saw. I then say something like "Thanks for the patch!! I fixed a few things in e5cbda" I feel like this is a highly valuable approach. The contributor appreciates being thanked, and also appreciates directly seeing the ways that their patch could have been better. This is antithetical to the "google style" of code review, where every single thing is nit-picked and the author must fix it. I think that approach only works well when you already have an established membership to that culture of code review (particularly if you are getting paid for it). With that approach, all of the bad behaviors get beaten out of contributors, and they eventually learn their lesson, and either leave or become good contributors. I think this can scare some people off, that might otherwise become regular contributors. Who knows if this will work out, but I think it is really worth a shot! Especially if the wiki is updated to indicate that there is now an "easy mode" for contributing to ghc. -Michael On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald wrote:

...

In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

What's even nice about this is its future proof and even agnostic to how the contributor made the change set locally! They could use mercurial or fossil for all we care. Or github. Or whatever!

My personal stance is that ghc already way easier to contribute to / get involved with than it was 2-5 years ago. This is even more impressive when you consider the number of contributors (who aren't students) that focus on ghc work full time has actually DECREASED over that period.

Community engagement / management is a totally orthogonal skill from contributing. Both take effort. Guiding new contributors requires both.

My personal stance is that ghc keeps on getting better and getting more contributors. And occasionally chatting about ways to make things better that we have the bandwidth to do is something that should happen every year or so. Like a health checkup.

I suspect one funnel for improvement may be figuring out how to make it more visible how many contributors / how actively deved various subsystems are. I feel like many new folks veer towards subsystems that are already actively worked on, which are often the ones that are both the most mature and thus hardest to easily contribute to! Perhaps I should see if there's an easy way to quantify that in a way that's easy to communicate to new contributors. There's an interesting data presentation challenge in that!

I've definitely found that for new potential contributors that orienting them to focus on subsystem that's important but doesn't get much activity leads to more successful first contributions. But that requires someone actively helping orient folks, which I like to think I've helped out with at points in recent years. Making this something that's easy to point at / discover along with "newcomer tickets" might help a lot

Tweaking the way we do tickets or code review I think doesn't change the important / fundamental challenges of doing a good patch for a project like ghc or llvm. (I think in some ways that llvm / gcc / clang are the right size projects to compare ghc against )

On Saturday, September 24, 2016, Brandon Allbery wrote:

...
On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty wrote:

...
Why are you so hostile to Chris? I don’t think that this is an appropriate way to treat somebody who is making a suggestion in good faith.

It may be in good faith. but it's not in good sense. There is a lot in the background that made Rust's setup possible, and he's not bringing that to the table, just assuming it'll somehow happen or that everyone else will drop everything for the next few months and make it happen. And I feel like he's being really pushy about committing already overworked people to this --- and insisting that anyone opposed must have a hidden agenda or otherwise cannot possibly have good reason to be opposed. It's not helpful at all; it's basically a good way to stall ghc for the next few months at least.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

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

Phyx

2:49 a.m.

I dislike this approach, having to already deal with a project that does patches via mailing lists it is very hard to follow conversations. As soon as multiple people get involved things fall apart. I have multiple mailing rules and other things just so I can keep track of comments. And then volume makes patches disappear into a void. We already have a lightweight process. Lots of people just attach the patch to trac. And we still accept it. Going to trac forces you to give me useful information about what you are trying to fix. A mailing list doesn't force a submitter to give me basic information about the patch. Such as which platform it effects. Also you can use phabricator.haskell.org without arc. You can manually upload a patch file to it. Again, phabricator's summerary file I find very useful. It may be annoying for drive by commiters, but when I have to come back to this code a year or so later, I need to know why it was added. On Mon, Sep 26, 2016, 07:34 Michael Sloan wrote:

...

I like this solution a lot, Carter!

Mailing patches directly to the ghc-devs list could be intimidating for newcomers. Having a list specific to patch review could make the process less intimidating. From a perspective of overall contribution intimidation, these 2 pages make it seem like a ton of extra work to contribute to GHC:

1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs 2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures

Of course, I understand that these exist for a reason. Contributing to GHC isn't easy, and it does need processes, and those processes should be followed!

However, for documentation patches and minor fixes, these pages make it seem like you really have to put in quite a bit to get started, and that the process is bureaucratic. Atop getting accounts setup and figuring out how to get ghc compiled, the amount of time investment to get in a simple patch already seems like it is on the order of hours, if not a full days worth of work.

At the risk of accumulating spam, perhaps the list shouldn't even require membership? Just have it filter based on containing an attachment (perhaps even require a "*.patch" attachment?)

I also think that there should be an easy way to put a stop to iterating via email and sending .patch files, and escalate to a phabricator review. Perhaps this could be scripted? Is there any way for people to use phabricator without using archanist? Not a criticism of the tech, but it is more to learn, and foreign to most.

One thing I've learned from maintaining stack, is that it can be really helpful to accept patches that are imperfect. Here's how this works:

1) Some user wants to fix something, and doesn't quite nail it. Maybe makes some style mistakes, spelling errors in comments, or perhaps writes some part of the code in a less direct way than possible

2) If the overall change is an improvement and the fixes are easy, I go ahead and merge the imperfect patch, and then commit my own fixes to the issues I saw. I then say something like "Thanks for the patch!! I fixed a few things in e5cbda"

I feel like this is a highly valuable approach. The contributor appreciates being thanked, and also appreciates directly seeing the ways that their patch could have been better.

This is antithetical to the "google style" of code review, where every single thing is nit-picked and the author must fix it. I think that approach only works well when you already have an established membership to that culture of code review (particularly if you are getting paid for it). With that approach, all of the bad behaviors get beaten out of contributors, and they eventually learn their lesson, and either leave or become good contributors. I think this can scare some people off, that might otherwise become regular contributors.

Who knows if this will work out, but I think it is really worth a shot! Especially if the wiki is updated to indicate that there is now an "easy mode" for contributing to ghc.

-Michael

...
In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

What's even nice about this is its future proof and even agnostic to how

...
contributor made the change set locally! They could use mercurial or fossil for all we care. Or github. Or whatever!

My personal stance is that ghc already way easier to contribute to / get involved with than it was 2-5 years ago. This is even more impressive when you consider the number of contributors (who aren't students) that focus on ghc work full time has actually DECREASED over that period.

Community engagement / management is a totally orthogonal skill from contributing. Both take effort. Guiding new contributors requires both.

My personal stance is that ghc keeps on getting better and getting more contributors. And occasionally chatting about ways to make things better that we have the bandwidth to do is something that should happen every year or so. Like a health checkup.

I suspect one funnel for improvement may be figuring out how to make it more visible how many contributors / how actively deved various subsystems are. I feel like many new folks veer towards subsystems that are already actively worked on, which are often the ones that are both the most mature and

...
hardest to easily contribute to! Perhaps I should see if there's an easy way to quantify that in a way that's easy to communicate to new contributors. There's an interesting data presentation challenge in that!

I've definitely found that for new potential contributors that orienting them to focus on subsystem that's important but doesn't get much activity leads to more successful first contributions. But that requires someone actively helping orient folks, which I like to think I've helped out with at points in recent years. Making this something that's easy to point at / discover along with "newcomer tickets" might help a lot

Tweaking the way we do tickets or code review I think doesn't change the important / fundamental challenges of doing a good patch for a project

...
ghc or llvm. (I think in some ways that llvm / gcc / clang are the right size projects to compare ghc against )

On Saturday, September 24, 2016, Brandon Allbery wrote:

...
On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty wrote:

...
Why are you so hostile to Chris? I don’t think that this is an appropriate way to treat somebody who is making a suggestion in good

faith.

...
It may be in good faith. but it's not in good sense. There is a lot in

...
...
background that made Rust's setup possible, and he's not bringing that to the table, just assuming it'll somehow happen or that everyone else will drop everything for the next few months and make it happen. And I feel

...
...
he's being really pushy about committing already overworked people to

On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald wrote: the thus like the like this

...
...
--- and insisting that anyone opposed must have a hidden agenda or otherwise cannot possibly have good reason to be opposed. It's not helpful at all; it's basically a good way to stall ghc for the next few months at least.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ 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

Ben Gamari

2:49 p.m.

Phyx writes:

...

I dislike this approach, having to already deal with a project that does patches via mailing lists it is very hard to follow conversations. As soon as multiple people get involved things fall apart.

I think accepting pull requests via GitHub can be done with minimal involvement from existing contributors. All we need is one or two people to keep an eye on the PR queue and merge or transition-to-Phabricator PRs as they arrive.

...

I have multiple mailing rules and other things just so I can keep track of comments. And then volume makes patches disappear into a void.

We already have a lightweight process. Lots of people just attach the patch to trac. And we still accept it.

Going to trac forces you to give me useful information about what you are trying to fix. A mailing list doesn't force a submitter to give me basic information about the patch. Such as which platform it effects.

A commit message as you are forced to provide by Git should usually be sufficient here. Of course, there are always cases where users will offer insufficient commit descriptions, but this is something that only the pull request monitors should need to worry about. Cheers, - Ben

John Wiegley

noon

...

...
...
...
...
"CS" == Carter Schonwald writes:

CS> What if simple small patches (such as hypothetical drive by doc patches ) CS> had a mailing list where folks could email the simple / small patches as CS> email attachments plus a body text that summarizes the patch, what it CS> does, and why it's simple! Btw, the "patchwork" system was created to do just this: Observe patches sent to a mailing list, and collect them into a web-based list, where discussion and review can happen in a patch-centric way. Example: https://patchwork.kernel.org/project/kvm/list/ The Linux project has been using this system to manage patch contributions for many years now. It may be a bit too webby, but it's example of another system that tries to address this bit of the process. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

Ben Gamari

2:45 p.m.

Carter Schonwald writes:

...

In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list. The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree. Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves. Cheers, - Ben

Michael Sloan

3:07 p.m.

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like: """ Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """ The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands: * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data. * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master. How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that". -Michael On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote:

...

Carter Schonwald writes:

...
In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree.

Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves.

Cheers,

- Ben

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

Michael Sloan

3:09 p.m.

Argh, sent too soon. The first paragraph, revised: This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow. On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote:

...
Carter Schonwald writes:

...
In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree.

Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves.

Cheers,

- Ben

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

Manuel M T Chakravarty

11:09 p.m.

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. Manuel

...

Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote:

...
Carter Schonwald writes:

...
In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree.

Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves.

Cheers,

- Ben

_______________________________________________ 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

Richard Eisenberg

27 Sep 27 Sep

11:46 a.m.

To sum up, this proposes the following: 1. Allow PRs on GitHub. 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors. 3. Small GitHub PRs can be merged directly, by ghc-hub. 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution. Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while. Is this worth sending through ghc-proposals? Thanks for volunteering item (2), Michael! Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...

On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

...
Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote:

...
Carter Schonwald writes:

...
In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree.

Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves.

Cheers,

- Ben

_______________________________________________ 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

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

Michael Sloan

5:32 p.m.

You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow: 0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator. Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following: 3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course. This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though! Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity. -Michael On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote:

...

To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

...
Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote:

...
Carter Schonwald writes:

...
In writing the following huge wall of text, I had and idea that I think many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple!

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree.

Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves.

Cheers,

- Ben

_______________________________________________ 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

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

Richard Eisenberg

9:47 p.m.

So you're suggesting that GitHub would function as a sort of alternate front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly dislike arc, which tries to be too clever for my tastes. Provided the integration works smoothly, I quite like this idea. Richard

...

On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote:

You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow:

0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator.

Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though!

Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote:

...
To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

...
Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote:

...
Carter Schonwald writes:

> In writing the following huge wall of text, I had and idea that I think > many folks would find palatable: > > What if simple small patches (such as hypothetical drive by doc patches ) > had a mailing list where folks could email the simple / small patches as > email attachments plus a body text that summarizes the patch, what it does, > and why it's simple! > I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree.

Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves.

Cheers,

- Ben

_______________________________________________ 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

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

Michael Sloan

10:22 p.m.

Exactly! So we will be using Phabricator for the review process, but with the github PRs you can use plain git. This means that new contributors will only need to learn about phabricator, and arc will be non-mandatory though probably recommended. Glad you like the idea :) -Michael On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg wrote:

...

So you're suggesting that GitHub would function as a sort of alternate front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly dislike arc, which tries to be too clever for my tastes. Provided the integration works smoothly, I quite like this idea.

Richard

...
On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote:

You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow:

0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator.

Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though!

Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote:

...
To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

...
Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: > Carter Schonwald writes: > >> In writing the following huge wall of text, I had and idea that I think >> many folks would find palatable: >> >> What if simple small patches (such as hypothetical drive by doc patches ) >> had a mailing list where folks could email the simple / small patches as >> email attachments plus a body text that summarizes the patch, what it does, >> and why it's simple! >> > I completely agree that for small (e.g. documentation) patches our > current system is quite heavy. For this reason I suggested at ICFP that > we simply begin accepting small patches via GitHub pull requests. > Frankly, this is less work for me than merging patches from a mailing > list and I believe many users feel that GitHub is more accessible than a > mailing list. > > The problem of course is what subset of patches do we want to allow to > be taken via GitHub. My suggested answer to that is any patch which, if > I were to write it myself, I would feel comfortable pushing directly to > the tree. > > Then there is the question of what do we do with pull requests opened > which do not satisfy this criterion. In this case I would likely open a > Phabricator Differential with the pull request and close the pull > request with a link to the Diff. In the ideal case this will inspire the > contributor to join the review process on Phabricator; in the worst case > review turns up issues in the patch and the user gives up. Either way, at > least the contributor feels his patch has been seen and given the > attention it deserves. > > Cheers, > > - Ben > > _______________________________________________ > 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

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

Simon Marlow

28 Sep 28 Sep

4:44 a.m.

Well, let's be careful here. I like the idea, but it's not a complete solution for people who don't want to use arc, because you can't revise a patch after submission in response to reviews, you would have to open a new PR. Perhaps you could build something that would allow revisions to PRs too... that would be cool. Cheers Simon On 28 September 2016 at 03:22, Michael Sloan wrote:

...

Exactly! So we will be using Phabricator for the review process, but with the github PRs you can use plain git. This means that new contributors will only need to learn about phabricator, and arc will be non-mandatory though probably recommended.

Glad you like the idea :)

-Michael

...
So you're suggesting that GitHub would function as a sort of alternate front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly dislike arc, which tries to be too clever for my tastes. Provided

On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg wrote: the integration works smoothly, I quite like this idea.

...
Richard

...
On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote:

You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow:

0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator.

Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though!

Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg

...
...
...
To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty < chak@justtesting.org> wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

...
Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: > This sounds like an ideal solution, Ben! As has been discussed many > times before, GitHub has many users familiar with its interface. By > allowing GitHub PRs, the initial contribution > > I think it would be acceptable for larger GitHub PRs to have some > automated boilerplate response. Ideally this would look like: > > """ > Thanks for making this patch! I've turned this into a Phab > Differential xxx and closed this PR. Please create a differential > account associated with your email address ..." > """ > > The email address can be automatically pulled from commit metadata. > If one is absent, then this automated process isn't possible. If it > is present and > > So, I'm imagining a utility that interfaces between both GitHub and > Phab,allowing the following commands: > > * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates

...
...
...
...
...
> patch to differential. It may attempt to migrate body and title of > the initial post, but lets not bother with migrating any review data. > > * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the > patch. This is used for merging small patches. It would not do an > automated push. Maybe have "--push" also perform the push? So like > if you are on master, then "ghc-hub merge > https://github.com/ghc/ghc/pull/1 --push" would merge the patches and > push to master. > > How does this sound? I like the idea a lot, and would enjoy helping > with implementation, time permitting. I could possibly start hacking > on it if others give the go ahead of "Yes, lets do that". > > -Michael > > On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >> Carter Schonwald writes: >> >>> In writing the following huge wall of text, I had and idea that I

...
...
...
...
...
>>> many folks would find palatable: >>> >>> What if simple small patches (such as hypothetical drive by doc

...
...
...
...
...
>>> had a mailing list where folks could email the simple / small

...
...
...
...
...
>>> email attachments plus a body text that summarizes the patch, what it does, >>> and why it's simple! >>> >> I completely agree that for small (e.g. documentation) patches our >> current system is quite heavy. For this reason I suggested at ICFP

...
...
...
...
...
>> we simply begin accepting small patches via GitHub pull requests. >> Frankly, this is less work for me than merging patches from a mailing >> list and I believe many users feel that GitHub is more accessible

...
...
...
...
...
>> mailing list. >> >> The problem of course is what subset of patches do we want to allow to >> be taken via GitHub. My suggested answer to that is any patch which, if >> I were to write it myself, I would feel comfortable pushing

wrote: the think patches ) patches as that than a directly to

...
...
...
...
...
>> the tree. >> >> Then there is the question of what do we do with pull requests opened >> which do not satisfy this criterion. In this case I would likely open a >> Phabricator Differential with the pull request and close the pull >> request with a link to the Diff. In the ideal case this will inspire the >> contributor to join the review process on Phabricator; in the worst case >> review turns up issues in the patch and the user gives up. Either way, at >> least the contributor feels his patch has been seen and given the >> attention it deserves. >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> 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

_______________________________________________ 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

Ben Gamari

12:06 p.m.

Simon Marlow writes:

...

Well, let's be careful here. I like the idea, but it's not a complete solution for people who don't want to use arc, because you can't revise a patch after submission in response to reviews, you would have to open a new PR.

I have considered building something like this in the past since posting series of patches via Arc is exceedingly painful. It's not entirely clear what it would look like, but I was thinking the tool would, 1. take a branch of commits, for instance, A -- B -- C -- D -- E -- F -- origin/master ^ HEAD 2. allow you to decide how to break it into Diffs. for instance, new diff A B new diff C D E new diff F which would produce three diffs: * one containing commits A and B * one containing commits C, D, and E * another containing F 3. run `arc diff` to upload each Diff to Phabricator, setting up the appropriate dependency structure between the created Diffs 4. rewrite history of your branch to add an annotation to the commit messages saying which diff each belongs to You are then free to continue modifying and even rebasing your branch and later the tool can be used to update the diffs from the current state of your branch. The tool could do this automatically, reconstructing where each commit belongs from the annotations added during upload. That being said, I ultimately decided it would be easier to just continue carrying out this workflow by hand considering I don't post large series of patches *that* often. I'm also a bit more eager to squash now than I used to be, in part due to the pain of submitting fine-grained patch sets. On the whole I do wish that Phabricator were more Git-like. Cheers, - Ben

Michael Sloan

4:03 p.m.

On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote:

...

That being said, I ultimately decided it would be easier to just continue carrying out this workflow by hand considering I don't post large series of patches *that* often. I'm also a bit more eager to squash now than I used to be, in part due to the pain of submitting fine-grained patch sets. On the whole I do wish that Phabricator were more Git-like.

Indeed, I do not know the details of phab / arc, but when encountering them, the workflow seemed unlike ordinary git workflows. It felt like it is working hard to implement an atypical git workflow, and learning this new workflow takes work. From the perspective of a contributor, it seemed strange since git's usual workflows are wildly successful and popular. Granted, it is easy for people to screw those up too, such as by using "git pull" instead of "git pull --rebase" orso. -Michael

Moritz Angermann

8:44 p.m.

I don't think Phabricator tries to be or emulate fit in any way; I think this is a misconception. The way I see it, phabricator is just a glorified diff-dump, which is supposed to work with any VCS in principle. All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to. By default arc does not preserve history if memory serves me right but uses the summary field exclusively for the commit message. Hence you can go wild on your local branches (use what ever development model suites your needs) and get one final squashed commit with an extensive summary. In my experience much of the frustration with arc comes from trying to use arc as git and grafting a hit workflow onto arc. To me, git is the organizing (branches and commits) and snapshotting solution to keep me sane and allow for experimentations without fear of loosing anything. Arc however is the tool that allows me to take my local mess and manage it as a reviewable patch I can update from my local tree if need be. Cheers, Moritz Sent from my iPhone

...

On 29 Sep 2016, at 4:03 AM, Michael Sloan wrote:

...
On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote: That being said, I ultimately decided it would be easier to just continue carrying out this workflow by hand considering I don't post large series of patches *that* often. I'm also a bit more eager to squash now than I used to be, in part due to the pain of submitting fine-grained patch sets. On the whole I do wish that Phabricator were more Git-like.

Indeed, I do not know the details of phab / arc, but when encountering them, the workflow seemed unlike ordinary git workflows. It felt like it is working hard to implement an atypical git workflow, and learning this new workflow takes work. From the perspective of a contributor, it seemed strange since git's usual workflows are wildly successful and popular. Granted, it is easy for people to screw those up too, such as by using "git pull" instead of "git pull --rebase" orso.

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

Ben Gamari

9:37 p.m.

Moritz Angermann writes:

...

I don't think Phabricator tries to be or emulate fit in any way; I think this is a misconception. The way I see it, phabricator is just a glorified diff-dump, which is supposed to work with any VCS in principle.

All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to.

By default arc does not preserve history if memory serves me right but uses the summary field exclusively for the commit message.

Hence you can go wild on your local branches (use what ever development model suites your needs) and get one final squashed commit with an extensive summary.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs. Cheers, - Ben

Moritz Angermann

10:27 p.m.

...

...
Hence you can go wild on your local branches (use what ever development model suites your needs) and get one final squashed commit with an extensive summary.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

Yes, this has been a constant source of frustration for us as well. Dealing with dependent diffs is just plain painful with arc :( What I usually end up doing, and I assume that’s what you are describing is: Turning A -- B -- C -- D -- E -- F -- origin/master ^ HEAD into: branch B1: E -- F -- origin/master / branch B2: C -- D / branch B3: A -- B and producing three diffs: $ git checkout E $ arc diff origin/master # producing D1 $ git checkout C $ arc diff B1 # adding “depends on D1" into the summary field $ git checkout A $ git diff B2 # adding “depends on D2” into the summary field and then rebase B2 and B3 when changes to D1 on B1 are necessary. Running `arc patch` with dependent diffs often resulted in trouble; this seems to be getting better with the staging areas though. So clearly we can see there are drawbacks. All I wanted to say in the previous email was essentially that from my experience frustration with arc often came from trying to make arc be git. Cheers, Moritz

Simon Marlow

1 Oct 1 Oct

4:47 p.m.

A nice trick for dealing with stacked diffs in Phabricator is to use "git rebase -i" to modify diffs in the middle of the stack. You can also insert "x arc diff" between lines to automatically update later diffs on Phabricator after a rebase lower down the stack. You only need a single branch for the whole stack, and continually rebase it. I also push the whole branch to github to get Travis to build it, but that's optional. Cheers Simon On 29 September 2016 at 03:27, Moritz Angermann wrote:

...

...
...
Hence you can go wild on your local branches (use what ever development model suites your needs) and get one final squashed commit with an extensive summary.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

Yes, this has been a constant source of frustration for us as well. Dealing with dependent diffs is just plain painful with arc :( What I usually end up doing, and I assume that’s what you are describing is:

Turning

A -- B -- C -- D -- E -- F -- origin/master ^ HEAD

into:

branch B1: E -- F -- origin/master / branch B2: C -- D / branch B3: A -- B

and producing three diffs:

$ git checkout E $ arc diff origin/master # producing D1

$ git checkout C $ arc diff B1 # adding “depends on D1" into the summary field

$ git checkout A $ git diff B2 # adding “depends on D2” into the summary field

and then rebase B2 and B3 when changes to D1 on B1 are necessary.

Running `arc patch` with dependent diffs often resulted in trouble; this seems to be getting better with the staging areas though.

So clearly we can see there are drawbacks. All I wanted to say in the previous email was essentially that from my experience frustration with arc often came from trying to make arc be git.

Cheers, Moritz

Brandon Allbery

4:49 p.m.

On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow wrote:

...

A nice trick for dealing with stacked diffs in Phabricator is to use "git rebase -i" to modify diffs in the middle of the stack. You can also insert "x arc diff" between lines to automatically update later diffs on Phabricator after a rebase lower down the stack.

You only need a single branch for the whole stack, and continually rebase it. I also push the whole branch to github to get Travis to build it, but that's optional.

Perhaps someone could put a sample workflow on (one of...) the wiki(s). -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Simon Marlow

5 Oct 5 Oct

10:27 a.m.

I added a description of the workflow for multiple dependent diffs here: https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Workingwithmultipledepende... Please let me know if anything doesn't make sense. Note that I never let arc squash my commits, keeping commits 1:1 with diffs makes things a lot simpler. On 1 October 2016 at 21:49, Brandon Allbery wrote:

...

On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow wrote:

...
A nice trick for dealing with stacked diffs in Phabricator is to use "git rebase -i" to modify diffs in the middle of the stack. You can also insert "x arc diff" between lines to automatically update later diffs on Phabricator after a rebase lower down the stack.

You only need a single branch for the whole stack, and continually rebase it. I also push the whole branch to github to get Travis to build it, but that's optional.

Perhaps someone could put a sample workflow on (one of...) the wiki(s).

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Eric Seidel

29 Sep 29 Sep

1:58 a.m.

On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:

...

Moritz Angermann writes:

...
All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

I completely understand how this would be frustrating for core contributors (more specifically for people submitting large patches), but for new or casual contributors it's actually quite freeing. I don't have to worry about how messy my local history gets, because arc will throw it all away regardless! It absolves me of an extra responsibility, and lowers the barrier to contributing. It would be nice to support both workflows though :)

Michael Sloan

6:05 a.m.

On Wednesday, September 28, 2016, Eric Seidel wrote:

...

On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:

...
Moritz Angermann javascript:;> writes:

...
All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

I completely understand how this would be frustrating for core contributors (more specifically for people submitting large patches), but for new or casual contributors it's actually quite freeing. I don't have to worry about how messy my local history gets, because arc will throw it all away regardless! It absolves me of an extra responsibility, and lowers the barrier to contributing.

I dislike this workflow because I am already used to doing a lot of git rebasing / amending / auto squashing. So using arc means taking away my ability to write multi commit stories of how the change was crafted. For large changes there are often multiple logical inter related steps. Squashing them into one big commit makes it much harder to review. I can easily do that myself by marking everything as squash in a rebase. It feels like arcanist is just taking away power, not giving it (note i have not used it much - voice of a newbie here) I am beginning to change my feelings on this, away from thinking of GitHub as an auxilliary source of didferentials. Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used. -Michael

...

It would be nice to support both workflows though :) _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Christopher Allen

10:20 a.m.

...

Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

Many problems are caused by letting your inner tinkerer/genius tailor dictate how things should be dealt with. Better to cut the gordian knot. I think Michael's right. On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan wrote:

...

On Wednesday, September 28, 2016, Eric Seidel wrote:

...
On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:

...
Moritz Angermann writes:

...
All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

I completely understand how this would be frustrating for core contributors (more specifically for people submitting large patches), but for new or casual contributors it's actually quite freeing. I don't have to worry about how messy my local history gets, because arc will throw it all away regardless! It absolves me of an extra responsibility, and lowers the barrier to contributing.

I dislike this workflow because I am already used to doing a lot of git rebasing / amending / auto squashing. So using arc means taking away my ability to write multi commit stories of how the change was crafted. For large changes there are often multiple logical inter related steps. Squashing them into one big commit makes it much harder to review. I can easily do that myself by marking everything as squash in a rebase. It feels like arcanist is just taking away power, not giving it (note i have not used it much - voice of a newbie here)

I am beginning to change my feelings on this, away from thinking of GitHub as an auxilliary source of didferentials. Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

-Michael

...
It would be nice to support both workflows though :) _______________________________________________ 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

-- Chris Allen Currently working on http://haskellbook.com

Richard Eisenberg

2:55 p.m.

I have tried to gather the ideas from this thread into a formal proposal: https://github.com/ghc-proposals/ghc-proposals/pull/11 Please feel free to make suggestions to improve this, especially if I've captured anyone's contributions incorrectly. -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...

On Sep 29, 2016, at 10:20 AM, Christopher Allen wrote:

...
Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

Many problems are caused by letting your inner tinkerer/genius tailor dictate how things should be dealt with. Better to cut the gordian knot. I think Michael's right.

On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan wrote:

...
On Wednesday, September 28, 2016, Eric Seidel wrote:

...
On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:

...
Moritz Angermann writes:

...
All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

I completely understand how this would be frustrating for core contributors (more specifically for people submitting large patches), but for new or casual contributors it's actually quite freeing. I don't have to worry about how messy my local history gets, because arc will throw it all away regardless! It absolves me of an extra responsibility, and lowers the barrier to contributing.

I dislike this workflow because I am already used to doing a lot of git rebasing / amending / auto squashing. So using arc means taking away my ability to write multi commit stories of how the change was crafted. For large changes there are often multiple logical inter related steps. Squashing them into one big commit makes it much harder to review. I can easily do that myself by marking everything as squash in a rebase. It feels like arcanist is just taking away power, not giving it (note i have not used it much - voice of a newbie here)

I am beginning to change my feelings on this, away from thinking of GitHub as an auxilliary source of didferentials. Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

-Michael

...
It would be nice to support both workflows though :) _______________________________________________ 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

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Boespflug, Mathieu

4:55 p.m.

Hi Richard! thanks for creating the pull request with a full proposal. You beat me to it - tried writing up much the same before stopping for dinner, essentially capturing just one of the points in Moritz's earlier (large) proposal. Moritz, I would encourage you like Richard did earlier to split the remaining points in your proposal into separate PR's too. So Richard, I created a PR to your PR to add in a little bit more detail: keeping the two mirrors in sync, role of the release manager to ensure that adequate reviewers get identified so that patches don't go unnoticed by an interested party who'd specifically want to review the patch on Phabricator, etc. https://github.com/goldfirere/ghc-proposals/pull/1 I also moved one of the two choices you mention to the "alternatives" section of the document, thinking that's the pupose of the section. On another note, I solicited an experience report from Gabriel Scherer earlier this week. The Ocaml community likewise pondered using GitHub back in 2014, and in fact lauched an experiment to that effect. So I was curious to hear how it went after 2 years of data. You can see the announcement here: http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30 Gabriel tells me that the initial situation for Ocaml was different from that of GHC: they had no formal code review tool in use, but would swap around patches on the Mantis issue tracker. Be it as it may, it's interesting to note just how much the number of contributions to Ocaml has increased in recent years, after this experiment started: https://github.com/ocaml/ocaml/graphs/contributors This experiment is today considered a big success. A key ingredient I gather is that Gabriel volunteered to triage the GitHub PR's and play the go-between to make sure all Mantis users were aware of any proposed changes relevant to them. The key insight I would put forth here is that how-to-accept-patches and where-to-review-them should be an agreement between the contributor and the assigned reviewer(s), in particular for trivial changes. For any given patch, provided the reviewer(s) is/are game, and provided all protential reviewers are made aware of its existence, it shouldn't matter much whether the patch came from Trac, Phabricator or GitHub. PS: Gabriel was very kind to also point out that the LLVM community has been big users of Phabricator and pondering introducing GitHub into the mix too. The discussion there should be relevant to this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html Best, -- Mathieu Boespflug Founder at http://tweag.io. -- Mathieu Boespflug Founder at http://tweag.io. On 29 September 2016 at 20:55, Richard Eisenberg wrote:

...

I have tried to gather the ideas from this thread into a formal proposal: https://github.com/ghc-proposals/ghc-proposals/pull/11

Please feel free to make suggestions to improve this, especially if I've captured anyone's contributions incorrectly.

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 29, 2016, at 10:20 AM, Christopher Allen wrote:

...
Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

Many problems are caused by letting your inner tinkerer/genius tailor dictate how things should be dealt with. Better to cut the gordian knot. I think Michael's right.

On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan wrote:

...
On Wednesday, September 28, 2016, Eric Seidel wrote:

...
On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:

...
Moritz Angermann writes:

...
All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or

...
...
...
...
(--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to.

Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone

existing patches

...
...
...
with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

I completely understand how this would be frustrating for core contributors (more specifically for people submitting large patches), but for new or casual contributors it's actually quite freeing. I don't have to worry about how messy my local history gets, because arc will throw it all away regardless! It absolves me of an extra responsibility, and lowers the barrier to contributing.

I dislike this workflow because I am already used to doing a lot of git rebasing / amending / auto squashing. So using arc means taking away my ability to write multi commit stories of how the change was crafted. For large changes there are often multiple logical inter related steps. Squashing them into one big commit makes it much harder to review. I can easily do that myself by marking everything as squash in a rebase. It feels like arcanist is just taking away power, not giving it (note i have not used it much - voice of a newbie here)

I am beginning to change my feelings on this, away from thinking of GitHub as an auxilliary source of didferentials. Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

-Michael

...
It would be nice to support both workflows though :) _______________________________________________ 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

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ 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

Matthew Pickering

5:33 p.m.

Thanks for the useful data point Mathieu. I think it should also be noted that GHC contributions spiked after switching to phabricator so it could just be the effect of moving to *some* code review tool. Could you perhaps summarise the salient points in the LLVM thread? It is very long with lots of discussion points. FWIW, I think that we should accept pull requests but only if they are mirrored and reviewed on phabricator. This is important for three reasons: 1. Reviewers only need to look in one place and can clearly see when they are expected to review. Herald rules will also not trigger if a pull request is solely dealt with on github which could mean the right eyes don't land on the ticket. 2. Pull requests (differentials) are able to be referred to by their unique differential number rather than the pull request identifier which clashes with trac ticket numbers. 3. Differentials integrate (and are able to be integrated) with the existing infrastructure. I hope that in the future we improve this integration by moving the issue tracker to maniphest. Facebook have a bot which does the mirroring for some of their repositories but it isn't open-sourced. I believe we should be trying to consolidate rather than spread everything even thinner. Matt On Thu, Sep 29, 2016 at 9:55 PM, Boespflug, Mathieu wrote:

...

Hi Richard!

thanks for creating the pull request with a full proposal. You beat me to it - tried writing up much the same before stopping for dinner, essentially capturing just one of the points in Moritz's earlier (large) proposal. Moritz, I would encourage you like Richard did earlier to split the remaining points in your proposal into separate PR's too.

So Richard, I created a PR to your PR to add in a little bit more detail: keeping the two mirrors in sync, role of the release manager to ensure that adequate reviewers get identified so that patches don't go unnoticed by an interested party who'd specifically want to review the patch on Phabricator, etc.

https://github.com/goldfirere/ghc-proposals/pull/1

I also moved one of the two choices you mention to the "alternatives" section of the document, thinking that's the pupose of the section.

On another note, I solicited an experience report from Gabriel Scherer earlier this week. The Ocaml community likewise pondered using GitHub back in 2014, and in fact lauched an experiment to that effect. So I was curious to hear how it went after 2 years of data.

You can see the announcement here:

http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30

Gabriel tells me that the initial situation for Ocaml was different from that of GHC: they had no formal code review tool in use, but would swap around patches on the Mantis issue tracker. Be it as it may, it's interesting to note just how much the number of contributions to Ocaml has increased in recent years, after this experiment started:

https://github.com/ocaml/ocaml/graphs/contributors

This experiment is today considered a big success. A key ingredient I gather is that Gabriel volunteered to triage the GitHub PR's and play the go-between to make sure all Mantis users were aware of any proposed changes relevant to them.

The key insight I would put forth here is that how-to-accept-patches and where-to-review-them should be an agreement between the contributor and the assigned reviewer(s), in particular for trivial changes. For any given patch, provided the reviewer(s) is/are game, and provided all protential reviewers are made aware of its existence, it shouldn't matter much whether the patch came from Trac, Phabricator or GitHub.

PS: Gabriel was very kind to also point out that the LLVM community has been big users of Phabricator and pondering introducing GitHub into the mix too. The discussion there should be relevant to this thread:

http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html

Best,

-- Mathieu Boespflug Founder at http://tweag.io.

-- Mathieu Boespflug Founder at http://tweag.io.

On 29 September 2016 at 20:55, Richard Eisenberg wrote:

...
I have tried to gather the ideas from this thread into a formal proposal: https://github.com/ghc-proposals/ghc-proposals/pull/11

Please feel free to make suggestions to improve this, especially if I've captured anyone's contributions incorrectly.

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 29, 2016, at 10:20 AM, Christopher Allen wrote:

...
Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

Many problems are caused by letting your inner tinkerer/genius tailor dictate how things should be dealt with. Better to cut the gordian knot. I think Michael's right.

On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan wrote:

...
On Wednesday, September 28, 2016, Eric Seidel wrote:

...
On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:

...
Moritz Angermann writes:

> All that arc essentially does is, compute the diff from an offset > (e.g. master) to the current HEAD and upload that to a new or > existing > (--update) differential. It also adds some meta information about > the > range, such that arc patch supposedly knows into which commit to > apply > the patch to. > Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs.

I completely understand how this would be frustrating for core contributors (more specifically for people submitting large patches), but for new or casual contributors it's actually quite freeing. I don't have to worry about how messy my local history gets, because arc will throw it all away regardless! It absolves me of an extra responsibility, and lowers the barrier to contributing.

I dislike this workflow because I am already used to doing a lot of git rebasing / amending / auto squashing. So using arc means taking away my ability to write multi commit stories of how the change was crafted. For large changes there are often multiple logical inter related steps. Squashing them into one big commit makes it much harder to review. I can easily do that myself by marking everything as squash in a rebase. It feels like arcanist is just taking away power, not giving it (note i have not used it much - voice of a newbie here)

I am beginning to change my feelings on this, away from thinking of GitHub as an auxilliary source of didferentials. Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used.

-Michael

...
It would be nice to support both workflows though :) _______________________________________________ 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

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ 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

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

Ben Gamari

10:53 p.m.

Matthew Pickering writes:

...

Thanks for the useful data point Mathieu. I think it should also be noted that GHC contributions spiked after switching to phabricator so it could just be the effect of moving to *some* code review tool. Could you perhaps summarise the salient points in the LLVM thread? It is very long with lots of discussion points.

As far as I know the LLVM folks were merely considering moving from SVN to Git, using GitHub to host their reposistory. I don't believe that moving to GitHub for issue tracking, code review, or any other functionality was ever seriously on the table. Cheers, - Ben

David Turner

2:12 a.m.

Hi, You can alter the content of a GitHub PR after its initial creation. The semantics of a PR is "please merge my branch named B into your repo" where the branch B is a mutable pointer to a commit. A workflow I've used a few times is to craft a nice sequence of commits for review and, once accepted, updated the PR to a squashed version of the same. Not that I like squashing, but that's what upstream wanted. In fact, the mutability of a PR is something you have to be a bit careful about on GitHub as you may not be accepting what you reviewed. It doesn't seem very easy to see how the branch has changed over time: there is no audit facility. I'd have thought the tooling discussed earlier should be able to take care of this problem. Cheers, On 28 Sep 2016 09:44, "Simon Marlow" wrote:

...

Well, let's be careful here. I like the idea, but it's not a complete solution for people who don't want to use arc, because you can't revise a patch after submission in response to reviews, you would have to open a new PR.

Perhaps you could build something that would allow revisions to PRs too... that would be cool.

Cheers Simon

On 28 September 2016 at 03:22, Michael Sloan wrote:

...
Exactly! So we will be using Phabricator for the review process, but with the github PRs you can use plain git. This means that new contributors will only need to learn about phabricator, and arc will be non-mandatory though probably recommended.

Glad you like the idea :)

-Michael

...
So you're suggesting that GitHub would function as a sort of alternate front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly dislike arc, which tries to be too clever for my tastes. Provided

On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg wrote: the integration works smoothly, I quite like this idea.

...
Richard

...
On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote:

You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow:

0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator.

Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though!

Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg <

...
...
...
To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty < chak@justtesting.org> wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

> Michael Sloan : > > Argh, sent too soon. The first paragraph, revised: > > This sounds like an ideal solution, Ben! As has been discussed many > times before, GitHub has many users familiar with its interface. By > allowing GitHub PRs, the initial contribution barrier will be lowered. If > there is an easy and straightforward process for shifting big

...
...
...
...
> to Phabricator, then people who are regularly contributing via GitHub > PRs can be incrementally on-boarded to the Phabricator / Arcanist > workflow. > > On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >> This sounds like an ideal solution, Ben! As has been discussed many >> times before, GitHub has many users familiar with its interface. By >> allowing GitHub PRs, the initial contribution >> >> I think it would be acceptable for larger GitHub PRs to have some >> automated boilerplate response. Ideally this would look like: >> >> """ >> Thanks for making this patch! I've turned this into a Phab >> Differential xxx and closed this PR. Please create a differential >> account associated with your email address ..." >> """ >> >> The email address can be automatically pulled from commit metadata. >> If one is absent, then this automated process isn't possible. If it >> is present and >> >> So, I'm imagining a utility that interfaces between both GitHub and >> Phab,allowing the following commands: >> >> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates

...
...
...
...
>> patch to differential. It may attempt to migrate body and title of >> the initial post, but lets not bother with migrating any review data. >> >> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >> patch. This is used for merging small patches. It would not do an >> automated push. Maybe have "--push" also perform the push? So

...
...
...
...
>> if you are on master, then "ghc-hub merge >> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >> push to master. >> >> How does this sound? I like the idea a lot, and would enjoy helping >> with implementation, time permitting. I could possibly start hacking >> on it if others give the go ahead of "Yes, lets do that". >> >> -Michael >> >> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>> Carter Schonwald writes: >>> >>>> In writing the following huge wall of text, I had and idea that I think >>>> many folks would find palatable: >>>> >>>> What if simple small patches (such as hypothetical drive by doc

...
...
...
...
>>>> had a mailing list where folks could email the simple / small

...
...
...
...
>>>> email attachments plus a body text that summarizes the patch, what it does, >>>> and why it's simple! >>>> >>> I completely agree that for small (e.g. documentation) patches our >>> current system is quite heavy. For this reason I suggested at ICFP that >>> we simply begin accepting small patches via GitHub pull requests. >>> Frankly, this is less work for me than merging patches from a mailing >>> list and I believe many users feel that GitHub is more accessible

...
...
...
...
>>> mailing list. >>> >>> The problem of course is what subset of patches do we want to allow to >>> be taken via GitHub. My suggested answer to that is any patch which, if >>> I were to write it myself, I would feel comfortable pushing

rae@cs.brynmawr.edu> wrote: patches the like patches ) patches as than a directly to

...
...
...
...
>>> the tree. >>> >>> Then there is the question of what do we do with pull requests opened >>> which do not satisfy this criterion. In this case I would likely open a >>> Phabricator Differential with the pull request and close the pull >>> request with a link to the Diff. In the ideal case this will inspire the >>> contributor to join the review process on Phabricator; in the worst case >>> review turns up issues in the patch and the user gives up. Either way, at >>> least the contributor feels his patch has been seen and given the >>> attention it deserves. >>> >>> Cheers, >>> >>> - Ben >>> >>> _______________________________________________ >>> 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

_______________________________________________ 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

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

Moritz Angermann

27 Sep 27 Sep

9:49 p.m.

Hi, I think it would be great if this was proposed formally. If we could integrate this with the improved ghc development proposal[1], this would be great! Or turn it into a separate proposal and remove the similar parts from the one mentioned. However, on the topic, I’d like to share a few thoughts: Do we know how many of these GitHub Pull Requests we will actually receive? If we migrate *everything* over to phabricator, isn’t that just going to increase complexity for most of the minor pull request? If someone fixes a spelling mistake or adds a short comment to explain something in more detail, I see no reason why we need to employ any heavy machinery and duplication across different tools. These, so I would hope, would be trivially merged by a small team of ghc devs watching the GitHub PR, especially if we don’t even know how much PRs we will receive through GitHub. On the other hand, if a PR is non-trivial (yes this is a bit of an ambiguous term), I’m in favor of asking the person who issued the PR to open an account with Phabricator[2], and run `$ arc diff origin/master` on his branch, or let us know that he considers this too much effort (and is willing to have someone else take over, should there be interest). The reasoning behind this is the following: first of all it’s the persons work, and unless someone else is willing to take it through the review process, this is going to end up being a dead diff in phabricator which adds additional overhead there. If there is not enough interest to follow a simple few steps document on how to push a non-trivial patch to phabricator, can we expect there to be sufficient interest in actually following up on the review process? I see this more as an onboarding problem than a continuous development issue. Those who are in the phabricator workflow, will likely just continue using it, no? I certainly would! However I might be browsing ghc source on GH just because I don’t have that code locally available right now and stumble on a spelling mistake, quickly use the editor provided by GH and submit one of these trivial PRs. Those who haven’t used phabricator yet, but are accustomed to the GH PR Flow, would start there and then be gently guided towards using phabricator and arc. We can do much better at explaining and showing the phabricator and arc workflow. In essence I’d like us see accepting GH Pull Requests and then do more data-driven on-demand incremental improvements, instead of trying to go all out with excessive tooling. Cheers, Moritz [1]: https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/... [2]: See the contributing to ghc section in [1].

...

On Sep 28, 2016, at 5:32 AM, Michael Sloan wrote:

You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow:

0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator.

Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though!

Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote:

...
To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

...
Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote:

...
Carter Schonwald writes:

> In writing the following huge wall of text, I had and idea that I think > many folks would find palatable: > > What if simple small patches (such as hypothetical drive by doc patches ) > had a mailing list where folks could email the simple / small patches as > email attachments plus a body text that summarizes the patch, what it does, > and why it's simple! > I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree.

Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves.

Cheers,

- Ben

_______________________________________________ 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

_______________________________________________ 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

Michael Sloan

10:20 p.m.

On Tue, Sep 27, 2016 at 6:49 PM, Moritz Angermann wrote:

...

Hi,

I think it would be great if this was proposed formally. If we could integrate this with the improved ghc development proposal[1], this would be great! Or turn it into a separate proposal and remove the similar parts from the one mentioned.

Cool! Should I do the integration? I wouldn't mind if someone else took these thoughts and integrated them, though I'd like to see how they get integrated!

...

However, on the topic, I’d like to share a few thoughts:

Do we know how many of these GitHub Pull Requests we will actually receive? If we migrate *everything* over to phabricator, isn’t that just going to increase complexity for most of the minor pull request?

We don't know how many, hopefully lots, right? What's the usual complexity for a minor patch to GHC - does it just skip differential and end up getting committed directly to master? In that case, yes this would cause there to be a lot more differentials. Is that a bad thing? We could certainly consider something more like the "ghc-hub" tool I've described elsewhere. This would give more direct control of what happens to GitHub PRs, but would also require manual oversight of incoming GitHub PRs.

...

If someone fixes a spelling mistake or adds a short comment to explain something in more detail, I see no reason why we need to employ any heavy machinery and duplication across different tools. These, so I would hope, would be trivially merged by a small team of ghc devs watching the GitHub PR, especially if we don’t even know how much PRs we will receive through GitHub.

On the other hand, if a PR is non-trivial (yes this is a bit of an ambiguous term), I’m in favor of asking the person who issued the PR to open an account with Phabricator[2], and run `$ arc diff origin/master` on his branch, or let us know that he considers this too much effort (and is willing to have someone else take over, should there be interest).

...

The reasoning behind this is the following: first of all it’s the persons work, and unless someone else is willing to take it through the review process, this is going to end up being a dead diff in phabricator which adds additional overhead there. If there is not enough interest to follow a simple few steps document on how to push a non-trivial patch to phabricator, can we expect there to be sufficient interest in actually following up on the review process?

I see this more as an onboarding problem than a continuous development issue. Those who are in the phabricator workflow, will likely just continue using it, no? I certainly would! However I might be browsing ghc source on GH just because I don’t have that code locally available right now and stumble on a spelling mistake, quickly use the editor provided by GH and submit one of these trivial PRs.

Exactly! GH has great support for creating trivial PRs. It is also a workflow people are familiar with. As soon as you ask people to install a piece of software and learn to use it (arcanist), there is immediately a cognitive barrier. Even if the software is easy to learn. I recall being confused about arcanist squashing, for example. I haven't used it in a long time, so I don't recall details. I can see the attitude of "Well, if you're hacking on GHC, you are probably capable of learning some new tools." This is true, but this stuff is adding cognitive load atop the existing cognitive load of creating a patch for GHC.

...

Those who haven’t used phabricator yet, but are accustomed to the GH PR Flow, would start there and then be gently guided towards using phabricator and arc. We can do much better at explaining and showing the phabricator and arc workflow.

Yup! That's how I see this as well. It is leveraging GH PRs as an easy way to attract contribution, but also guiding people towards Phabricator. As things stand, you need to learn both Phabricator and Arcanist at the same time. This way, we can start with onboarding people with phabricator, and later get them to start using archanist directly. Some won't make it to that stage, but it will still be valuable to get GH PRs from them!

...

In essence I’d like us see accepting GH Pull Requests and then do more data-driven on-demand incremental improvements, instead of trying to go all out with excessive tooling.

This is a wise approach! I think it makes sense to try the manual labor version of this process before automating it. Automation should be on the minds of those doing the work, though, and they can be reassured that it will get easier once automation is in place.

...

Cheers, Moritz

[1]: https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/... [2]: See the contributing to ghc section in [1].

...
On Sep 28, 2016, at 5:32 AM, Michael Sloan wrote:

You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow:

0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator.

Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though!

Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote:

...
To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

...
On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote:

Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.

Manuel

...
Michael Sloan :

Argh, sent too soon. The first paragraph, revised:

This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote:

...
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like:

""" Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """

The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and

So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master.

How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: > Carter Schonwald writes: > >> In writing the following huge wall of text, I had and idea that I think >> many folks would find palatable: >> >> What if simple small patches (such as hypothetical drive by doc patches ) >> had a mailing list where folks could email the simple / small patches as >> email attachments plus a body text that summarizes the patch, what it does, >> and why it's simple! >> > I completely agree that for small (e.g. documentation) patches our > current system is quite heavy. For this reason I suggested at ICFP that > we simply begin accepting small patches via GitHub pull requests. > Frankly, this is less work for me than merging patches from a mailing > list and I believe many users feel that GitHub is more accessible than a > mailing list. > > The problem of course is what subset of patches do we want to allow to > be taken via GitHub. My suggested answer to that is any patch which, if > I were to write it myself, I would feel comfortable pushing directly to > the tree. > > Then there is the question of what do we do with pull requests opened > which do not satisfy this criterion. In this case I would likely open a > Phabricator Differential with the pull request and close the pull > request with a link to the Diff. In the ideal case this will inspire the > contributor to join the review process on Phabricator; in the worst case > review turns up issues in the patch and the user gives up. Either way, at > least the contributor feels his patch has been seen and given the > attention it deserves. > > Cheers, > > - Ben > > _______________________________________________ > 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

_______________________________________________ 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

3279

Age (days ago)

3289

Last active (days ago)

List overview

Download

31 comments

15 participants

participants (15)

Ben Gamari
Boespflug, Mathieu
Brandon Allbery
Carter Schonwald
Christopher Allen
David Turner
Eric Seidel
John Wiegley
Manuel M T Chakravarty
Matthew Pickering
Michael Sloan
Moritz Angermann
Phyx
Richard Eisenberg
Simon Marlow