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

[Simon Peyton Jones]

| - 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:

  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

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.

It's worth noting that it's not so much "libraries that want to
be included in GHC", but rather "libraries that GHC's authors
would like to import in GHC's own source code, rather than
re-implementing that functionality (which would be silly)".

Simon

| -----Original Message-----
| From: John Ericson <john.ericson at obsidian.systems>
| Sent: 02 July 2019 17:00
| To: Henning Thielemann <lemming at henning-thielemann.de>; Simon Peyton Jones
| <simonpj at microsoft.com>
| Cc: ghc-devops-group at haskell.org; Michael Snoyman <michael at fpcomplete.com>;
| David Terei <code at davidterei.com>; Ashley Yakeley <ashley at semantic.org>;
| Herbert Valerio Riedel <hvr at gmail.com>; Haskell Libraries
| (libraries at haskell.org) <libraries at haskell.org>
| Subject: Re: [GHC DevOps Group] Making GHC's fast release cadence work
| 
| 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
| >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske
| ll.org%2Fcgi-
| bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft
| .com%7C6ae01104c4b345984a0208d6ff06464e%7C72f988bf86f141af91ab2d7cd011db47%
| 7C1%7C1%7C636976799775801107&sdata=YEf6lczTdY9Mp%2B6lFHzCdwcagiQWZ3VgxI
| QTfqH5ZXk%3D&reserved=0