<div dir="ltr">what lib didn't have a release that wouldn't work with the release candidate?<div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at 4:51 PM Boespflug, Mathieu <<a href="mailto:m@tweag.io">m@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">A related discussion came up previously: <a href="https://mail.haskell.org/pipermail/ghc-devops-group/2017-December/thread.html#118" target="_blank">https://mail.haskell.org/pipermail/ghc-devops-group/2017-December/thread.html#118</a>. From the moment that GHC accepts unreleased dependencies on its release branch, GHC developers lose full control over their own release timeline. Because a new GHC release can only ship when the dependencies have been released, the release process could block on upstream for indefinite periods of time, like is currently happening with at least one GHC dependency that has been blocked on the maintainer for at least 27 days (and counting).<div><br></div><div>It was suggested then that GHC should only use release versions of its dependencies on the master or release branch, and that if this isn't practical due to co-dependency, then that suggests said dependencies should have the same release cycle as GHC (i.e. same people can cut releases of both) or even be merged in GHC itself.<div><br clear="all"><div><div dir="ltr" class="gmail-m_-5144841499781315908gmail_signature">--<br>Mathieu Boespflug<br>Founder at <a href="http://tweag.io" target="_blank">http://tweag.io</a>.</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 Jul 2019 at 21:03, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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" rel="noreferrer" target="_blank">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
_______________________________________________<br>
Ghc-devops-group mailing list<br>
<a href="mailto:Ghc-devops-group@haskell.org" target="_blank">Ghc-devops-group@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>