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