<div dir="auto">I think it would be nice to start by letting the core library maintainers know your preferred release deadlines.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019, 1:22 PM Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
GHC's core libraries are a critical part of the Haskell ecosystem. I<br>
want to thank you for overseeing the maintenance of this infrastructure.<br>
<br>
However, for the last three weeks the release candidate for GHC 8.8.1<br>
has been ready aside from releases of a couple of our core libraries.<br>
<br>
Naturally, delays like this make it hard for GHC to maintain its faster<br>
release cycle. At the same time, we do not want this cadence to impose<br>
an undue burden on our core library maintainers.<br>
<br>
How do you think we might speed up this process?<br>
<br>
For instance, perhaps the GHC release manager could pick up<br>
some of the "boring parts" of core library maintenance limited to:<br>
<br>
 * Version bound bumps<br>
<br>
 * Changes of CPP conditionals to accommodate changes in the<br>
   compiler and other core libraries<br>
<br>
 * Changelog entries to describe these releases<br>
<br>
 * Uploading these releases or revisions to Hackage<br>
<br>
Of course, this would merely be an offer to maintainers; this would be<br>
GHC's way of carrying some of the burden that our release process<br>
imposes.<br>
<br>
In general, I am interested in a discussion on how to make this faster<br>
release pace work. Ideas?<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div>