New Libraries Proposal process
All, There is a new Libraries Proposal process, inspired by the GHC Proposals process. Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with. I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.
Where was this discussed or proposed? All libraries process needs to start
on the libraries mailing list. And soemtimes Perhaps moving to clc list for
resolving tie breaking on controversial choices.
The libraries archive goes back pretty far and email threading seems to
scale far better for participating in complex discussions than does githubs
comment collapsing on large discussions.
On Fri, Sep 11, 2020 at 3:20 PM chessai
All,
There is a new Libraries Proposal process, inspired by the GHC Proposals process.
Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive.
Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.
I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
Please resurrect this project. Things never get done in this mailing list. Literally, a module is missing a fold — and even this triviality is never going to get fixed.
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. :)
On Wed, Jun 30, 2021 at 3:07 PM Ignat Insarov
Please resurrect this project. Things never get done in this mailing list.
Literally, a module is missing a fold — and even this triviality is never going to get fixed. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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?
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
Thanks Julian. Last time I opened an issue to `containers` they sent me straight to this mailing list. So I assumed the same would happen if I make a pull request to add something to `base`. But maybe you are right and it is going to go differently. I am going to try it and report back.
On Thu, Jul 01, 2021 at 01:54:15PM +0500, Ignat Insarov wrote:
Last time I opened an issue to `containers` they sent me straight to this mailing list. So I assumed the same would happen if I make a pull request to add something to `base`. But maybe you are right and it is going to go differently. I am going to try it and report back.
What might help in this case is some motivating context that would help to overcome the objection that you're suggesting yet more partial functions for Data.Foldable, which perhaps belong in a new Foldable1 class, of which 'NonEmpty' can be the poster-child instance. Would 'Foldable1' work for you? Do you need it to be derivable? ... -- Viktor.
participants (5)
-
Carter Schonwald -
chessai -
Ignat Insarov -
Julian Ospald -
Viktor Dukhovni