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

[Ashley Yakeley]

Thinking about this, it seems like the root cause of the problem is
that the relationship between GHC and the core libraries is awkwardly
caught between two different models.

In one model, the libraries are part of GHC, so the library maintainers
are part of the GHC release team, that happen to be assigned these
particular GHC features. If one member of the team can't work on their
GHC feature for whatever reason, another member can step in.

In the other model, the libraries are dependencies of GHC. GHC can make
requests upstream to the libraries, but will have to wait or work
around any issues in the mean time.

-- Ashley

On Mon, 2019-07-01 at 13:22 -0400, Ben Gamari wrote:
> Hi everyone,
> 
> GHC's core libraries are a critical part of the Haskell ecosystem. I
> want to thank you for overseeing the maintenance of this
> infrastructure.
> 
> However, for the last three weeks the release candidate for GHC 8.8.1
> has been ready aside from releases of a couple of our core libraries.
> 
> Naturally, delays like this make it hard for GHC to maintain its
> faster
> release cycle. At the same time, we do not want this cadence to
> impose
> an undue burden on our core library maintainers.
> 
> How do you think we might speed up this process?
> 
> For instance, perhaps the GHC release manager could pick up
> some of the "boring parts" of core library maintenance limited to:
> 
>  * Version bound bumps
> 
>  * Changes of CPP conditionals to accommodate changes in the
>    compiler and other core libraries
> 
>  * Changelog entries to describe these releases
> 
>  * Uploading these releases or revisions to Hackage
> 
> Of course, this would merely be an offer to maintainers; this would
> be
> GHC's way of carrying some of the burden that our release process
> imposes.
> 
> In general, I am interested in a discussion on how to make this
> faster
> release pace work. Ideas?
> 
> Cheers,
> 
> - Ben
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20190702/706826d1/attachment.html>