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

From the moment that GHC accepts unreleased dependencies on its release branch, GHC developers lose full control over their own release timeline. Because a new GHC release can only ship when the dependencies have been released, the release process could block on upstream for indefinite

A related discussion came up previously: https://mail.haskell.org/pipermail/ghc-devops-group/2017-December/thread.htm.... periods of time, like is currently happening with at least one GHC dependency that has been blocked on the maintainer for at least 27 days (and counting). It was suggested then that GHC should only use release versions of its dependencies on the master or release branch, and that if this isn't practical due to co-dependency, then that suggests said dependencies should have the same release cycle as GHC (i.e. same people can cut releases of both) or even be merged in GHC itself. -- Mathieu Boespflug Founder at http://tweag.io. On Mon, 1 Jul 2019 at 21:03, David Feuer wrote:

I realize that my response came off as rather unfriendly. I'm sorry about that. Thinking a bit more about it, I think GHC HQ can help Core Library maintainers in several unintrusive ways. Here are a couple I would appreciate myself; others may disagree.

1. Work with Herbert, Ryan, etc., to make it easy to use -Werror in Travis scripts. See https://github.com/haskell/containers/pull/645

2. Give us a nudge when you have a release timeframe in mind. "We're hoping to have the core libraries ready for release by December 5" (several weeks beforehand, repeated a couple times thereafter with appropriate adjustments) is much less stressful than "We're basically ready for release but we're waiting on core libraries."

On Mon, Jul 1, 2019, 1:30 PM David Feuer wrote:

...

I think it would be nice to start by letting the core library maintainers know your preferred release deadlines.

On Mon, Jul 1, 2019, 1:22 PM 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

_______________________________________________ Ghc-devops-group mailing list Ghc-devops-group@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group