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

[Richard Eisenberg]

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 <cma at bitemyapp.com> 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 <mgsloan at gmail.com> wrote:
>> 
>> 
>> On Wednesday, September 28, 2016, Eric Seidel <eric at seidel.io> wrote:
>>> 
>>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
>>>> Moritz Angermann <moritz at lichtzwerge.de> 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 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
>> 
> 
> 
> 
> -- 
> Chris Allen
> Currently working on http://haskellbook.com
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs