Notes from Ben's "contribute to ghc" discussion

Simon Marlow marlowsd at gmail.com
Mon Sep 26 09:24:26 UTC 2016


I would rather we *didn't* accept contributions via github, even for small
patches, and instead put more effort into streamlining the Phabricator
workflow.

   - Adding another input method complicates the workflow, users have to
   decide which one to use
   - Github is not integrated with our other infrastructure, while
   Phabricator is
   - Mutliple sources of contributions makes life harder for maintainers

Let's make the Phabricator workflow easier.

   - Why not put arc in the repo, or provide a script that automatically
   downloads it and sets it up?
   - I also like the idea of auto-push if validate succeeds.  Or a button
   that you can press on the diff that would do the same thing, so you can get
   code review first.
   - +1 to making the manual easier to build.  The same goes for Haddocks;
   it's really hard to make a simple patch to the docs and test it right now.

One other thing that came up but wasn't mentioned in the notes: let's be
more prompt about reverting patches that break validate, even if they only
break a test.  Now that we have better CI support, we can easily identify
breaking patches and revert them.

Cheers

Simon

On 24 September 2016 at 02: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 <http://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160926/d1d5b1db/attachment.html>


More information about the ghc-devs mailing list