<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I would be happy to assist with the Win32 library and/or be part of
the "windows task force".<br>
<br>
I'm no Haskell expert but I do use GHC extensively on Windows for a
few of our production apps.<br>
<br>
-- Andrew Klingenberg<br>
<br>
<br>
<div class="moz-cite-prefix">On 2015-02-28 21:39, Edward Kmett
wrote:<br>
</div>
<blockquote
cite="mid:CAJumaK9UjS2wR0GnsjdvN1+i9kCBucVsqHhJ6Kahc2Tt3uHBoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>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.</div>
<div><br>
</div>
<div>In response to that feedback, we've recently taken the
time to go through and update the <a moz-do-not-send="true"
href="https://wiki.haskell.org/Library_submissions">Library_submissions</a> page
rather extensively to better describe and refine the
libraries@ process and better define the role of the core
libraries committee.</div>
</div>
<div><br>
</div>
<div>Changes of note:</div>
<div><br>
</div>
<div>* 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 <a
moz-do-not-send="true"
href="https://wiki.haskell.org/Library_submissions">Library_submissions</a> page
with a detailed summary of what libraries are considered
"core" and why.</div>
<div><br>
</div>
<div>* 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. </div>
<div><br>
</div>
<div>Communication:</div>
<div><br>
</div>
<div>There are two forms of potential communication breakdowns
that we'd like to address.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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
<a moz-do-not-send="true"
href="https://wiki.haskell.org/Library_submissions#Responsiveness">responsiveness
guidelines</a> 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.</div>
<div><br>
</div>
<div>Maintainership:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Emboldened by this success, we have a few other packages
with which we'd like to do the same:</div>
<div><br>
</div>
<div>* random </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>* unix</div>
<div><br>
</div>
<div>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.</div>
</div>
<div><br>
</div>
<div>* Win32</div>
<div><br>
</div>
<div>None of us on the current core libraries committee are <i>particularly</i>
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?</div>
<div><br>
</div>
<div>* old-time, old-locale, haskell98 and haskell2010</div>
<div><br>
</div>
<div>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 <a
moz-do-not-send="true"
href="https://ghc.haskell.org/trac/ghc/ticket/9590">#9590</a>)
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.</div>
<div><br>
</div>
<div>Thank you for your time. Please do not hesitate to contact
me (or reply) with questions, concerns, or thoughts.</div>
<div><br>
</div>
<div>-Edward Kmett</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
<br>
</body>
</html>