Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

There is a phabricator module, ponder [1], which looks suitable for
the Q&A feature. Surely we all agree that it is easier to setup this
module than to host a completely separate service ourselves! This also
has the advantage of being able to reference commits, differentials
and tickets in an easy manner.

Another question about administration, it doesn't seem like many
people have permissions to modify the phabricator installation. How
easy is it to give some people more elevated positions to deal with
things like updating the home page, giving badges, moderating "ponder"
and so on? The homepage hasn't been updated for quite a while, the
"recent events" tab makes it look like the project is quite dead.

If anyone has ever talked to me about this, it should be clear that I
am a massive phabricator fanboy and think that we should utilise it
more. There are lots of modules [2] that we don't use and the product
is just going to get better as other companies (ie facebook) continue
to drive it. I think that in the future it would be beneficial to port
the wiki and bug tracker from trac to the corresponding phabricator
features, phriction and maniphest respectively. Firstly, I think
phabricator is just better than trac but the primary reason is that
trac is not very actively developed.

So three separate thoughts in this email, only one of which is
relevant to the thread. With regards to the other points in Simon's
email, I don't feel qualified to opine too much as GHC is the only
"large" project I have contributed to. Bear that in mind when reading
my comments inline below. I'll make sure to check out the video when
it is released as well.

[1]: https://secure.phabricator.com/ponder/
[2]: https://secure.phabricator.com/w/starmap/

> ·        Doc bugs.    Two kinds
>
> o   Typos.   Friction stops me
>
> o   Explanations needed e.g. read/show

The biggest friction is the fact some of the user guide is generated
so you have to build the whole compiler to build the user guide. It
seems like it would be possible to
just not include this generated section if you wanted to compile the
guide in order to check you didn't make a syntax mistake or something.
Perhaps it would be good if the build bots made the generated user
guide available for each build it did. I don't know how feasible this
is.

>
> ·        Lightweight pushes

What does this mean?

>
> ·        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.

Submodules are annoying to update, everyone knows this. Separating out
the two makes synchronous updates harder to review together but makes
drive-by updates easier. I think it would be nice if there was a
web-interface which allowed people to edit the user guide in the
browser rather than have to setup an entire development environment.

>
> ·        Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.

This seems like a reasonable idea but perhaps not worth the effort
needed to set it up. My usual workflow is to put most of my commits
onto phabrictor with the thought that
it's better for less people to directly interact with the main branch.
If Ben would prefer less control then I can merge more things myself
without issues!

>
> ·        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.

I think a consistent style wouldn't be a bad thing. The code is a bit
strange as Simon perfers the semi-colon style which not many people
other than him in the whole community
uses. The more pressing concern to me is the scale of the API to some
modules is very large, there are lots of exposed functions which
aren't documented at all which do slightly different things with
subtle invariants. A much more beneficial change would be to enforce
that new library style functions should get haddock comments saying
what they do! Cutting back these APIs is hard as it requires a very
good knowledge of the compiler which not many people have.



> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>