Library_submissions and Call for Maintainers

Elliot Robinson elliot.robinson at
Sun Mar 1 05:09:36 UTC 2015

I would be happy to assume maintainership of `unix` with the goal of bringing order to cross-platform chaos. I'll also continue backing up Phil as a secondary maintainer of `directory`.

Elliot Robinson

On 02/28/15, 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

More information about the Libraries mailing list