<div dir="ltr"><div>Thanks for spelling this out Gershom. Reading it through, here are my questions:</div><div><br></div><div>1. What's the definition of "feature freeze"? Does it mean API stability? Does it mean not code changes at all except to fix a bug? Are performance fixes allowed in that case?</div><div>2. What's the minimum time between GHC cutting a feature-freeze branch and the first release candidate? And the minimum time between first release candidate and official release? Obviously, if each of these is 1 week (which I can't imagine would be the case), then these libraries could cut a feature-freeze branch after the official release, which obviously isn't intended. I apologize if these timings are already well established, I'm not familiar enough with GHC release cadence to know.</div><div><br></div><div>I can't speak to GHC development itself, but from a downstream perspective, this sounds like the right direction.<br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 18, 2017 at 9:41 PM, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let me try to formulate a synthetic policy as per Simon's request:<br>
<br>
Policy:<br>
Bundled library maintainers agree to the following:<br>
  1) When GHC cuts a feature-freeze branch, they too (if anything has<br>
changed) cut a feature-freeze branch within two weeks at the maximum<br>
(ideally sooner), to be included in the main GHC freeze branch. If<br>
they do not do so, the last released version will be included instead.<br>
  2) When GHC releases the first release candidate, maintainers (if<br>
anything has changed) release new versions of their packages, to then<br>
be depended on directly in the GHC repo. All submodules are then<br>
replaced with their proper released versions for GHC release.<br>
<br>
This policy can be enforced by GHC hq as part of the release process<br>
with the exception of a case in which there's coupling so that a new<br>
GHC _requires_ a new submodule release, and also the maintainer is not<br>
responsive. We'll have to deal with that case directly, likely by just<br>
appealing to the libraries committee or something to force a new<br>
release :-)<br>
<br>
Motivation:<br>
This should help address multiple issues: 1) holdup of ghc on other<br>
releases. 2) lack of synchronization with ghc and other releases. 3)<br>
low lead-time for people to adapt to API changes in forthcoming<br>
library releases tied to ghc releases. In particular, because Cabal is<br>
part of this policy, it should help circumvent the sorts of problems<br>
that led to this thread initially. Further, because this only applies<br>
to freeze/release branches, it should not slow down<br>
rapid-implementation of cross-cutting changes more generally.<br>
<br>
Cheers,<br>
<div class="m_-2053273032196907851HOEnZb"><div class="m_-2053273032196907851h5">Gershom<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div></div>