You want to change base. base release schedule is tied to GHC and is in fact part of its git tree: https://gitlab.haskell.org/ghc/ghc/-/tree/master/libraries/base
By providing a clear patch with reasoning and motivation, you're reducing the possibility of bikeshedding.
ML is for bikeshedding and getting a picture of community opinion. I believe your patch doesn't require any of that. If the GHC team/CLC thinks so, they'll let you know on your PR.
My experience even with patches to core libraries is also mixed. Last time I tried to provide something as simple as forM to Data.Set. It took 1 year to even get to an actual review. Then the patch was 90% done, but failed because of the remaining 10% that the maintainers weren't able to make clear to me.
IMO, these days it's hard to get contributors anyway. I personally merge PRs even if they're just 80% done and fix the rest myself.
I don't expect there to be issues with base though. GHC developers are responsive.
On July 1, 2021 6:58:24 AM UTC, Ignat Insarov
Pull request on ghc gitlab and then link to it here for folks to review it.
Grounded patches solve all sorts of ambiguity. Having another proposal process doesn’t solve that. :)
Carter, I completely fail to understand any of your three sentences.
1. What does GHC have to do with any of this? I am talking about proposals to core libraries, not GHC. 2. What is a grounded patch? What is the ambiguity you are talking about? _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries