<div dir="auto">I realize that my response came off as rather unfriendly. I'm sorry about that. Thinking a bit more about it, I think GHC HQ can help Core Library maintainers in several unintrusive ways. Here are a couple I would appreciate myself; others may disagree.<div dir="auto"><br></div><div dir="auto">1. Work with Herbert, Ryan, etc., to make it easy to use -Werror in Travis scripts. See <a href="https://github.com/haskell/containers/pull/645">https://github.com/haskell/containers/pull/645</a></div><div dir="auto"><br></div><div dir="auto">2. Give us a nudge when you have a release timeframe in mind. "We're hoping to have the core libraries ready for release by December 5" (several weeks beforehand, repeated a couple times thereafter with appropriate adjustments) is much less stressful than "We're basically ready for release but we're waiting on core libraries."</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019, 1:30 PM David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank" rel="noreferrer">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>
</blockquote></div>