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

[Manuel M T Chakravarty]

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

Manuel

> Michael Sloan <mgsloan at gmail.com>:
> 
> 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 <mgsloan at gmail.com> 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 <ben at smart-cactus.org> wrote:
>>> Carter Schonwald <carter.schonwald at gmail.com> 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 at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs