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

[Ben Gamari]

David Feuer <david.feuer at gmail.com> writes:

> I think it would be nice to start by letting the core library maintainers
> know your preferred release deadlines.
>
Sure, that is reasonable. I do try to make the schedule clear in a few
places:

 * At the beginning of the release cycle I send an email to all core
   library authors outlining the release cycle. This email was sent in
   late-October in the case of 8.8.1.

 * Per-project tracking tickets for the release

 * Individual reminders via email and IRC

However, there no doubt could be more signalling throughout the process.
In particular, I can be more communicative about changes in the GHC
release process (e.g. letting core library maintainers know when we
anticipate a schedule slip, as we did due to the GitLab migration).

On the other hand, ideally GHC schedule changes wouldn't affect upstream
release schedules. I think we would all probably be better off if core
library upstreams try to keep releases for GHC small and boring. That
is, preparation of a core library release would consist of taking the
library's last major release, fixing any changed interfaces from
dependencies, bumping some bounds, and, when GHC leaves alpha, pushing
to Hackage. It's when a core library tries to synchronize its release
cycle with GHC that we run into issues [1].

Cheers,

- Ben


[1] Yes, sometimes a synchronized release schedule is necessary, but I
    think we should avoid synchronization whenever possible.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20190701/b3b1f77e/attachment-0001.sig>