Re: [GHC DevOps Group] Making GHC's fast release cadence work

The GHC release team is free to make a minor (patch-level) release of an existing released version of the library L, embodying any changes necessary to make the library work with the new version of GHC

Yeah I like that limitation. It is good to make my proposal less draconian :) Happy to hear that's what you wanted all along Ben! Ashley:

For the time library, I would rather the GHC team make a pull request first, and let me do the release. At the very least I want to know what's going on and what the needs are.

Adding to what Ben said, I think the way submodules work today mean that unmerged (e.g. just in the GHC fork) changes to a submodule block a PR? So only in repos where the PR happens to live in the same repo as master can GHC use the PR branch and still pass CI, and the usual case is the PR must be merged before GHC relies on it. I hope in the majority of cases these GHC-driven releases would just take stuff that is on master but unreleased, and therefore already reviewed the normal way. David:

It seems to mostly be an issue for stack, which wants a fully consistent package set.

Stackage should be comfortable building GHC itself with a newer containers then, I think. (And likewise for anyone that needs a newer containers in their build of the GHC library.) John On 7/2/19 12:46 PM, Ben Gamari wrote:

Simon Peyton Jones via Libraries writes:

...

| - the kicker: Any library that wishes to be included in GHC / base *must | share maintainership* with the GHC release team / libraries committee, | respectively/./ That means those groups can release things whenever they | want to unblock themselves.

That seems very plausible to me. But "sharing maintainership" could be limited to:

I think that is all that's needed. In general GHC should not rely on a bleeding-edge release of a library. But it's not uncommon for tiny changes to be needed, and by sharing maintainership, the library author would not need to be bothered about making and releasing those changes.

Yes, this is precisely what I was trying to articulate in my original email (although failed to do so clearly). We would not want to be responsible for managing major releases; merely incremental patch-level releases to patch things up to be shippable with GHC.

Cheers,

- Ben