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

[David Feuer]

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 <david.feuer at gmail.com> 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 <ben at well-typed.com> 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/20190701/a49f5d2a/attachment-0001.html>