Library_submissions and Call for Maintainers

Andrew Klingenberg asklingenberg at
Mon Mar 2 23:39:33 UTC 2015

I would be happy to assist with the Win32 library and/or be part of the 
"windows task force".

I'm no Haskell expert but I do use GHC extensively on Windows for a few 
of our production apps.

-- Andrew Klingenberg

On 2015-02-28 21:39, Edward Kmett wrote:
> We've had a lot of feedback over the last few months trying to get 
> clarification on the role of the core libraries committee, and on the 
> libraries@ process in general. In particular, Simon Peyton Jones asked 
> us in his own rather inimitable manner to make sure that we sat down 
> and started documenting things. After all, we've now been at this for 
> almost a year and a half, and have started to figure out what is 
> working and what isn't.
> In response to that feedback, we've recently taken the time to go 
> through and update the Library_submissions 
> <> page rather extensively 
> to better describe and refine the libraries@ process and better define 
> the role of the core libraries committee.
> Changes of note:
> * Up until now we've been using the rather ad hoc definition of "core 
> libraries" as libraries that come with the Haskell Platform and which 
> are subject to the libraries@ proposal process. We've recently taken 
> it upon ourselves to clarify this further. To that end we've updated 
> the Library_submissions 
> <> page with a detailed 
> summary of what libraries are considered "core" and why.
> * It was brought to our attention that figuring out even where to file 
> a bug report or feature request for a given library was a tricky 
> concern. To that end we've added information on how to find the 
> appropriate issue tracker to the form.
> Communication:
> There are two forms of potential communication breakdowns that we'd 
> like to address.
> We're still working on figuring out a more effective way to 
> communicate what changes are happening in the background out to the 
> community, lest we wind up with another situation like the 
> Foldable/Traversable Proposal, where it caught an appreciable segment 
> of the community unaware. We've started at least tracking issues that 
> impact modules defined in the Haskell report in GHC trac with 
> "report-impact", but we still have a lot more to do on this front.
> We have also been asked to help clarify what happens to a proposal 
> once it leaves the libraries@ mailing list, assuming that the proposal 
> is accepted by the maintainer. The issue was raised that it wasn't 
> clear when an issue had been dropped on the floor, and who has 
> responsibility to carry it forward at each stage along the way. To 
> that end, we've posted some basic responsiveness guidelines 
> <> to help. 
> We're not looking for a way to hold someone's feet to the fire, but 
> merely for a way to keep proposals from getting stuck in limbo as they 
> transition out of the libraries mailing list and into the hands of the 
> maintainers.
> Maintainership:
> In an effort to maintain a greater level of throughput on issues that 
> come along, we're trying to increase the number of projects that have 
> active maintainers. Some of these aren't necessarily core libraries, 
> but they are libraries that have been handed to the core libraries 
> committee for maintenance.
> A couple of weeks back we sought out an active maintainer for the 
> directory package, as it had accumulated several months worth of 
> backlogged tickets, most of which just needed a clear head to make an 
> informed decision about how to proceed. Phil Ruffwind and Elliot 
> Robinson stepped up to fill this gap, and have been making a rather 
> exciting amount of headway in clearing out the issue backlog, while 
> managing to give those issues the consideration they are due.
> Emboldened by this success, we have a few other packages with which 
> we'd like to do the same:
> * random
> We've had some truly excellent work done over the last couple of years 
> on how to deal with "splitting" a random number generator in a 
> cryptographically sound manner. I spent some time cleaning up a few 
> outstanding issues for this package personally over the summer, but 
> have not had nearly enough time to devote to the issue of how to 
> integrate the outcome of the recent research on splitting, while 
> simultaneously caring about performance and soundness.
> * unix
> We've had a number of issues accrete over time, particularly issues 
> that have to do with portability to lesser used platforms such as 
> OpenBSD. We've also had a lot of cooks in the kitchen, so the 
> documentation style for this library is all over the place. We could 
> use a solid maintainer for this package who is deeply familiar with 
> unix internals, and who, preferably would like to deal with bringing 
> some order to these cross platform concerns.
> * Win32
> None of us on the current core libraries committee are /particularly/ 
> well versed in current windows issues. We have a new "windows task 
> force" as well. Would the task force -- or someone involved or who 
> would like to be involved in it -- be willing to pick this up and 
> carry the torch?
> * old-time, old-locale, haskell98 and haskell2010
> The old-time and old-locale libraries are primarily maintained because 
> their contents are mentioned in the Haskell Report, which is/was 
> (mostly) implemented in the haskell98 and haskell2010 packages. Three 
> months ago, we determined to stop shipping these as boot libraries 
> with the GHC as a consequence of the Applicative-Monad Proposal. 
> (Issue #9590 <>) While 
> Herbert Valerio Riedel recently started working on a "fully compliant" 
> version of the Haskell 2010 report, there is a reasonably large design 
> surface in that area, balancing between perfect compatibility and 
> pragmatic compatibility with other libraries. These libraries could 
> use a more active official maintainer.
> Thank you for your time. Please do not hesitate to contact me (or 
> reply) with questions, concerns, or thoughts.
> -Edward Kmett
> _______________________________________________
> Libraries mailing list
> Libraries at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list