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

[John Ericson]

Yeah there are many interlocking issues here. I've been thinking about 
writing one of those ecosystem proposals about this. Here's some 
observations about the status quo for now.

- Frequent releases are a really nice for feature for the community. I 
know I, for one, would be less motivated to work on GHC if it would take 
a year in some case for my contributions to trickle back to my day job. 
Rust releases every 6 *weeks*. I see no reason why we shouldn't aim for 
that.

- The GitLab move and switch to CI have made GHC development more 
accessible and, temporary Marge Bot issues aside, better scaling. I am 
immensely grateful for those that put in the work for that every MR I 
write. Going back to annual releases would feel like a regression, 
cancelling out some of those gains.

- Base really is a PVP mess. Only the messy guts actually make sense to 
pair with GHC releases, a breaking change every time. The "pure" bits 
would naturally have *fewer* breaking releases, but *more* non-breaking 
releases.

- AMP-like proposals could probably move faster if they weren't tied to 
GHC releases. I.e. if multiple GHC releases supported multiple class 
hierarchies, people could move at their own pace to some extent, and we 
could support faster *and* slower migrations.

- I hope GHC can move in a more modular direction, which by definition 
means farming off work to libraries. In other words, I think GHC should 
ultimately have the same degree of code reuse as any other Haskell 
project. But the current experience with submodules is excruciating, so 
no one dealing with GHC every day rightfully has any appetite for that. 
It's a pity because once it's done I think it would be *less* work for 
the core GHC team, there's just the awkward transition out of today's 
monolithic local maximum.

So all this needs leads me to conclude a few things

- Base must be broken up, so it can be released more often than GHC. 
Base would continue to exist reexport code in other libraries 
exclusively. New users, executables, and legacy code can continue to 
depend on base as before, but libraries are encouraged to adopt more 
fine-grained dependencies on the underlying libraries.

- 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.
//

It's fairly clear-cut to me: having your library being included in GHC 
or base is a big honor, and so you should not be able to hold up the 
release process of these important projects unilaterally. If you want to 
keep full custody of your baby, that's fine, but it's worth not the 
precious time of the GHC/base developers to use it then. [Aim for, say, 
Haskell Platform inclusion rather than base inclusion.]

Granted, GHC, unlike Base, there is the alternative to use Cabal's new 
support for multiple versions of a package in the same package DB. But 
until will have private dependencies that would place some probably 
unpopular constraints on consumers of GHC-the-library. If GHC does 
migrate from ~10 to ~100 dependencies, maybe it might make sense to 
float that as an alternative, but seeing that is many GHC releases away 
no matter what, I think it's best to start with the shared 
maintainership policy.

  John

On 7/2/19 8:36 AM, Henning Thielemann wrote:
>
> On Tue, 2 Jul 2019, Simon Peyton Jones via Libraries wrote:
>
>>  1. What should GHC’s release cadence be? For example, would annual be
>>     better than semi-annual?  Herbert and
>>     Michael both think so, and they know a thing or two.   I’d love to
>>     hear from more people on this question.
>
> Annual is better for me. I do not need the latest and greatest GHC 
> features immediately. I am happy to get bugfixes quickly and easily 
> via hvr's ghc ppa.
>
> However, I'd prefer that libraries are separated from GHC and 'base' 
> would be split.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries