Opening up Cabal development

[Edward Z. Yang]

Excerpts from Oleg Grenrus's message of 2016-07-14 02:08:54 -0700:
> About convenience libraries I agree even more. We should discussed them more.
> There are questions I’d might to ask, but I guess it too late

It's not too late. They are not in any real release. They can be
removed.

> Or maybe not too late, but for another thread:
> what is convenience library name clashes with the library on package,
> say I define convenience library fancylib-lens, which is on Hackage, but maybe also after I made my package?
> I guess, some shadowing happens? Is there a warning?

Convenience library shadows the one on Hackage.  There's no warning
but it would be easy to add one; however, I don't think there should
be a warning--these names are just lexically scoped.

> But we have quite formal feeling proposals about `provides`,
> and `or-dependencies / multi-way-flag / depends`, and
> formal process would help to get them thru (or say no, with an explanation)

Yes. Especially when there are competing solutions and there
is not an obvious "best one".

> About the original topic, I’d require “ a history of quality contributions”, so something between (2) or (3).
> I don’t like many rules, also making fair but non-abusable ones is difficult, but as we have this conversation,
> the outcome should be well defined (also how we change the rules).
> As with (2) does every accepted PR counts, like single character typo fix in the documentation?
> And I don’t know how to define “quality contribution” :(

In the blog post linked, the suggestion was to apply discretion by
looking at the GitHub profile / erstwhile contribution history.

But yes, I DO think we should accept single character typo fixes!
That's how you get new contributors who help spruce up the
documentation.  We should trust but verify.

> (Maybe I’m just to scared about dramas happened elsewhere)

Too late; there's already drama ;)

> Related to this, a thought I had for some time:
> I’d like to split Cabal and cabal-install repositories.
> 
> Pros:
> - `cabal-install` can be much more liberal in giving out commit bits, as you cannot make too much damage here.
> - we already have `hackage-security` as a dependency between them.
> - the CI setup could be simplified, resulting into
> - their tests could do more things: `Cabal` parses all `Hackage`, changes to `cabal-install` doesn’t need to do it,
>   and vice-versa, fixing ui of cabal-install doesn’t need to do package tests of Cabal.
> - their other processes could be different too.
> 
> Cons: Simultaneous development is almost impossible. And this is almost a show-stopper.
> - `cabal-install` would need to lag one release behind `Cabal` (development agains released `Cabal`).
>   This could work as `Setup.hs` should work to install packages requiring newer Cabal (isn’t it how it works nowadays?).
>   There will be a problem when newer `Cabal` won’t accept build-plan created by solver
>   in older `cabal-install` (proposals mentioned above), but I hope it won’t be a huge issue.
> - To make this work we’d need to release more Cabal major versions,
>   so there aren’t many breaking and intrusive changes accumulating. But that’s good thing, isn’t it?
> 
> Or it could be a quality win to separate them. After all `cabal-install` is not the only consumer of `Cabal`.
> `stack` uses it very limitedly atm though (i.e. to extract dependencies and maybe verify install plan?)
> I don’t know what `ghc-pkg` does.
> 
> IMHO we should develop Cabal-the-library with highest standards (starting with having detailed CHANGELOG) for library development.
> Now we might have been too focused on developing Cabal for cabal-install. Cabal should provide quality plumbing support for “everyone”.
> (if we could start with a clean desk, i’d make Setup.hs and cabal-install commands different, that’s one confusing part).
> 
> The separation into different repositories would make things a bit clearer:
> Cabal-the-library and cabal-install are different things. (For example: cabal-install doesn’t parse *.cabal files).

Currently cabal-install is tightly coupled to Cabal.  I'm all for looser
coupling (e.g.,  https://github.com/haskell/cabal/issues/3549).
Separate repositories force this, but in general looser coupling will
lead to some short term pain.

Edward