Notes from Ben's "contribute to ghc" discussion

Alexander V Vershilov alexander.vershilov at gmail.com
Tue Sep 27 15:20:19 UTC 2016


I think I'm a bit late for the party.

I'm speaking with the newcomer hat on, as basically I have
contributed only few trivial patches. So not sure if my experience
matter.

Originally I was submitting patches using Trac, but then was kindly
asked (IIRC by Simon Marlow) to use Phab instead. Surprisingly enough
I had no problems with Phab, and setup took about 15 minutes
(most of that time I spend on php compilation). Student that I used
to co-mentor this year on HSoC also said that he had zero problems
with Phab and that it took 5 minutes to set everything up. So from
my personal point of view problem of the Phabricator are heavily
overrated.

Whenever you do non trivial (not simple documentation fix) amount
of work and documentation needs to be read highly preside the
complexity of the work for submitting patch. Review requests and
email that is sent is greatly structured, latest changes on  github
makes small step toward but anyway not that good. Also for almost
all the changes I had to contact #ghc or persons who is familiar with
that subsystem and always had great and prompt feedback.

What I'm written above doesn't mean that it's nowhere to improve.
Documentation on the wiki may be structured better and sometimes
it's very hard to get the actual state by reading it. Especially if there
was some ongoing discussion without highlighting the outcome.

As many already highlighted in this thread having a single account for
trac, phab and ideally popular system people people already use will be
beneficial.  Without that I think other improvements will not work well.

Also it would be nice if it was possible to automate some actions like
adding a link from trac to Phab. I remember spending much time on
trying to recall correct syntax to add link to Phab.

About GitHub based contribution. It looks great for me for *all
types* of the patches. But.. bot (or for some time person) should
migrate *all* the patches to Phab, closing the threads for comments.
Bot should write some welcome message than with a link to Phab
request and intruction how to allow Phab to use github account
and read email if there is no account yet.
This way when review had happened author will automatically receive
all review comments with links to Phab, I'll hardly get that following
a link to github is any harder than following link to Phab (assuming
Phab  to login using github account). If user addressed comment
he should be able to just force-push/update his branch and new revision
should be created by bot. PR on github should be closed whenever Phab
request will be closed, so it would be trackable using GitHub only.

This way github-ish users could use tool that they used to, but also
reviewers to use the tool they also used to. All the review
comments will be stored in the single place, no revisions will be lost.
This way could be automated and there will be no strange questions
about what is large patch and what is not. The only people who use
are ones that doesn't use email to receive review comments and can
use only GitHub interface to read that, but I doubt that such users exists.

--
Alexander

On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs
<ghc-devs at haskell.org> wrote:
> Friends
>
>
>
> Here are the notes I took from session 2 of the Haskell Implementors
> Meeting.  The bolding is my choice of emphasis.
>
>
>
> Simon
>
>
>
> ·        Doc bugs.    Two kinds
>
> o   Typos.   Friction stops me
>
> o   Explanations needed e.g. read/show
>
> ·        Lightweight pushes
>
> ·        Make user manual into its own repo, to make it easier to take pull
> requests.  But that makes it harder when making synchronised changes to GHC
> and user manual.
>
> ·        Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.
>
> ·        Style guides.  Is having a defined style solving a problem we don’t
> really have?  One piece of guidance: adhere to the style of the surrounding
> code.  Low priority.
>
> ·        Docker images.   We should have one.
>
> ·        Remove old documentation!
>
> ·        Cross compilation is difficult.
>
> ·        Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
> jakzale at gmail.com offers to do this! – thank you).  It has a useful new
> Documentation feature.   Eg this would be good for “how do I look up a
> RdrName to get a Name… there seem to be six different functions that do
> that”.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Alexander


More information about the ghc-devs mailing list