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

[Carter Schonwald]

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/25b6da70/attachment-0001.html>