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

[John Ericson]

> 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 <libraries at haskell.org> 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
>