How to start with GHC development?

[Simon Marlow]

On 18/12/12 15:51, Simon Peyton-Jones wrote:
> | > It seems that many informations in the wiki are duplicated. There are
> | > two pages about
> | > repositories:
> | > http://hackage.haskell.org/trac/ghc/wiki/Repositories
> | > http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Repositori
> | > es (after reading the first one source tree started to make much more
> | > sense - this is one of the informations *I* would like to get first).
> |
> | The first page lists the repositories and where the upstreams and
> | mirrors are.  The second page contains the conventions for working on
> | other repositories (which is why it's under WorkingConventions).
>
> Simon, I don't find that a clear distinction. Looking at the two, I'm a bit confused too!

So Repositories is "what repositories there are", and 
WorkingConventions/Repositories is "how to work on them".  Isn't that a 
clear distinction?

> * The lists on WorkingConventions/Repositories duplicates the table in Repositories.

There are two separate workflows, so we have to say which libraries each 
workflow applies to.  I'd be fine with merging this info with the other 
table - it might be slightly more awkward having the info on a separate 
page, but there would be only one list of repositories.

> * I believe that perhaps WorkingConventions/Repositories is solely concerned with how to *modify* a library; it opening para says as much.  Fine; but it shouldn't duplicate the info.

Right.

> Maybe the table could do with a column saying "GHC" or "Upstream" to specify the "how to modify" convention?  (I wish the table could somehow be narrower.  And that the library name was the first column.)  Perhaps the master table can look like this:
>
> What           GHC repo location                Upstream repo exists?
>                 http://darcs.haskell.org/
>
> GHC            ghc.git
> ghc-tarballs   ghc-tarballs.git
> ...etc...
> binary         binary.git                       YES
> ...etc...
>
> Then we can deal with the complexities of upstream repos in another page.  I think that might put the info in a way that's easier to grok.  I can do it if Simon and Ian agree; or Ian could.

Ok by me.

Cheers,
	Simon