Notes from Ben's "contribute to ghc" discussion

[Richard Fung]

>
> That is a great point; it's easy for me to forget how I felt when I was
> a beginner. I've added a brief paragraph to the Newcomers page,
>     If you have any questions along the way don't hesitate to reach out
>     to the community. There are people on the mailing lists and IRC who
>     will gladly help you (although you may need to be patient). Don't
>     forget that all GHC developers are still learning; your question is
>     never too silly to ask.
> Can you see any way this could be improved?



> That is a fair point; I've added some language to the Newcomers page
> encouraging these sorts of inqueries,
>     == Finding a ticket ==
>     Now that you can build GHC, let's get hacking. But first, you'll
>     need to identify a goal. GHC's Trac tickets are a great place to
>     find starting points. You are encouraged to ask for a starting point
>     on IRC or the ghc-devs mailing list. There someone familiar with the
>     process can help you find a ticket that matches your expertise and
>     help you when troubles arise.
>     If you want to get a taste for possible starting tasks, below is a
>     list of tickets that appear to be "low-hanging fruit" -- things that
>     might be reasonable for a newcomer to GHC hacking. Of course, we
>     can't ever be sure of how hard a task is before doing it, so
>     apologies if one of these is too hard.
> Is this better?


I think both of these are great. Thanks!

On Mon, Sep 26, 2016 at 2:51 PM, 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?
>
>
> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160926/6988fb29/attachment-0001.html>