Library_submissions and Call for Maintainers

[Andrew Klingenberg]

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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150302/ebf826af/attachment.html>