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

[Matthew Pickering]

Six months is even quite a long time between releases. What do other
projects do?

IMO, the main cause of this churn is the very incremental painful
refactoring of the core type classes. Are there any other changes
which regularly require library intervention?

Cheers,

Matt

On Tue, Jul 2, 2019 at 1:16 PM Simon Peyton Jones via Libraries
<libraries at haskell.org> wrote:
>
> It seems to me that both questions are sensible ones:
>
>
>
> 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.
>
>
>
> 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> wrote:
>
> On Mon, Jul 1, 2019 at 8:09 PM Ben Gamari <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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries