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

[Carter Schonwald]

err: which library lacked a release that worked with the 8.8 RC?

On Tue, Jul 2, 2019 at 12:25 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> what lib didn't have a release that wouldn't work with the release
> candidate?
>
>
>
> On Mon, Jul 1, 2019 at 4:51 PM Boespflug, Mathieu <m at tweag.io> wrote:
>
>> A related discussion came up previously:
>> https://mail.haskell.org/pipermail/ghc-devops-group/2017-December/thread.html#118.
>> 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
>> 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 <david.feuer at gmail.com> 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 <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
>>>>>
>>>>> _______________________________________________
>>> Ghc-devops-group mailing list
>>> Ghc-devops-group at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20190702/825e0fff/attachment.html>