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

[Simon Peyton Jones]

It seems to me that both questions are sensible ones:


  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.



  1.  When we do make a release, whenever that is, how we can work most productively with library authors, so that the release comes out in a timely way?  This was Ben’s original question, and it applies regardless of cadence.


Simon

From: Ghc-devops-group <ghc-devops-group-bounces at haskell.org> On Behalf Of Michael Snoyman
Sent: 02 July 2019 05:54
To: Herbert Valerio Riedel <hvriedel at gmail.com>
Cc: David Feuer <david.feuer at gmail.com>; ghc-devops-group at haskell.org; Ashley Yakeley <ashley at semantic.org>; Judah Jacobson <judah.jacobson at gmail.com>; David Terei <code at davidterei.com>; 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



On Tue, Jul 2, 2019 at 12:12 AM Herbert Valerio Riedel <hvriedel at gmail.com<mailto:hvriedel at gmail.com>> wrote:
On Mon, Jul 1, 2019 at 8:09 PM Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>> wrote:
> Naturally, delays like this make it hard for GHC to maintain its faster
release cycle
> ...
> How do you think we might speed up this process?

IMO You're asking the wrong question.

This seems based on a premise that everyone agreed with a faster
release cycle... to me the downsides on the ecosystem and
infrastructure of a faster release churn significantly outweight the
modest benefit some people might perceive; and the issue's we've been
observing (not only boot libraries, but also the 10k packages on
Hackage) with the overspeeded release cycle are IMO a sign that we're
moving faster than the ecosystem can accommodate. Just because GHC HQ
managed to optimize their release processes (and I have to say, at the
expense of the release quality -- GHC 8.6.5 was the first major
release since GHC's beginning to require five attempts -- and I have
to note that this results in annoying busy work for GHC packagers like
myself) doesn't mean that everyone else has the time and energy to
adapt to this new order as well.

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20190702/22c83f2a/attachment.html>