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

[Boespflug, Mathieu]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190701/3a24f36d/attachment.html>