Library_submissions and Call for Maintainers

Tue Mar 3 08:32:35 UTC 2015

Andrew

Excellent, thank you! I've added you to the Windows Task Force list
            https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Andrew Klingenberg
Sent: 02 March 2015 23:40
To: Edward Kmett; Haskell Libraries
Subject: Re: Library_submissions and Call for Maintainers

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 at haskell.org<mailto:Libraries at haskell.org>

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150303/896e1d0c/attachment-0001.html>