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 GPG Key: 9FEDE59A 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 https://wiki.haskell.org/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 https://wiki.haskell.org/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 https://wiki.haskell.org/Library_submissions#Responsiveness 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 https://ghc.haskell.org/trac/ghc/ticket/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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Sat, Feb 28, 2015 at 8:39 PM, Edward Kmett wrote:

* 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.

'random' has been on bad-footing for a while in terms of API and functionality. I can re-produce my issues if desired, but a core question seems to be acceptability. Is tf-random not pleasing to enough people? Or the splitting is too slow? I don't currently know of any users who want high performing _and_ cryptographically sound generators, though that would be great to have. I am only currently aware of cryptographic PRNGs with slow (ish) split times and statistically decent PRNGs with good split times. I've had to fix two commercial projects now that had used StdGen so I'm willing to do significant work getting a PRNG with both properties if we can quantify the performance requirements. So far my best options appear to be tf-random or a 800-90 style CTR DRBG that's computes large buffers resulting in high memory use and decent _amortized_ performance (including split). -TomMD

Edward Kmett writes:

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.

I'd like to throw my hat in the ring and become a co-maintainer also. I use random numbers a lot for various Monte Carlo simulations.

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 https://wiki.haskell.org/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 https://wiki.haskell.org/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 https://wiki.haskell.org/Library_submissions#Responsiveness 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 https://ghc.haskell.org/trac/ghc/ticket/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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Edward Kmett writes:

* 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.

I finally managed to get some time to start looking at this. I have created a ticket here https://github.com/haskell/random/issues/25 Please add comments and any information you think Carter and I might find helpful. I discovered the package has some benchmarks that are 3+ years old. At the moment, I am not sure what they are telling me. If anyone has any background / views please chip in. Dominic.