Notes from Ben's "contribute to ghc" discussion

[Simon Marlow]

On 26 September 2016 at 22:51, Ben Gamari <ben at smart-cactus.org> wrote:

> Simon Marlow <marlowsd at gmail.com> writes:
>
> > But this is opening the floodgates a crack... how do we know what a
> "small"
> > patch is?  What happens when someone submits a patch that's too large?
> >
> I tried to address these questions in the "Create a
> ghc-simple-patch-propose list?" thread where I said,
>
> Ben Gamari <ben at smart-cactus.org> writes:
>
> > 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.
>
> Does this help?
>

Well ok.  I'm still concerned that adding a new contribution method is not
making things simpler, and that we have even more process and things to
document, which might itself be discouraging to new users.  But if you say
it's easy for you to accept patches this way, and that the rest of us can
mostly ignore github then I guess that limits the downsides.

Of course if people say this is what they actually want, then who am I to
disagree :)

Cheers
Simon



>
>
> Simon Marlow <marlowsd at gmail.com> writes:
>
> > The patches will get larger, we'll have to do code reviews on two
> > different tools, and it will be really hard to go back. I just have a
> > bad feeling about this.
> >
> I share your worry that the GitHub patch sizes will "creep". That being
> said, I think that as long as we can easily move to Phabricator for
> reviewing larger patches it will be manageable.
>
> Moreover, I suspect that once someone has submitted a patch via GitHub,
> the effort that they have sunk into it will mean that they will be more
> likely to follow the patch to Phabricator to participate in review (and
> hopefully revision) if we move it.
>
> >> It does certainly put yet another task on our plates, but I would argue
> >> that it's actually easier than accepting patches via Trac, which we
> >> already do.
> >
> > We should stop accepting patches via Trac too :)
> >
> Heh, it would certainly make my life easier. That being said, there
> (thankfully) aren't too many that come in via this channel at this
> point.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160927/b5c5de10/attachment.html>