Opening up Cabal development

[Edward Z. Yang]

Excerpts from Gershom B's message of 2016-07-13 18:01:50 -0700:
> On July 13, 2016 at 7:32:47 PM, Edward Z. Yang (ezyang at mit.edu) wrote:
> 
> The general notion sounds good to me. I’m semi-indifferent between (1)
> and (2) though conservatively lean towards the latter.
> 
> > - The Travis build must always be green. We should prioritize
> > adding more tests for things we care about. Look into regular
> > Hackage tests.
> > - PR all your changes (so that you can check that Travis is green),
> > try to get approval for big changes but BE BOLD.
> 
> I’d add
> 
> - I don’t break backwards compat for APIs without notice and
> discussion, and don’t break backwards compat for any element of cabal
> files without lots of discussion.
> 
> (and I don’t know what tests would be necessary to help notice this,
> but they’d probably be useful!)

Simple, we need Hackage-level CI.  Here are few possible things to test:

   1. Can we parse all of Hackage?

   2. Can we build all of Stackage?
        https://groups.google.com/forum/#!msg/haskell-stack/oi-VJrAIJbE/FjAPVZTUAQAJ
      Attempting to build all of Hackage is dicey business because it
      is a combinatorial explosion, and you do not know what is supposed
      to build.  But Stackage is supposed to build. Test that

   3. Can we build all Setup.hs scripts on Hackage?  This lets us know
      which APIs in Cabal matter, and which ones we can change.
      We'll need to establish base truth for this.

It is a travesty that this infrastructure does not exist; it may even
be possible to do (1) and (3) on Travis, as they should not take too
long to do.

Edward