GHC release timing and future build infrastructure

[Bardur Arantsson]

On 2017-08-01 15:05, Ara Adkins wrote:
> Heya,
> 
> I very much agree with the thoughts on the variability of the release
> cadence. The following is somewhat of a stream of consciousness as I
> read, so please excuse any lack of coherence. 
> 
> When you talk about the bugs being significant blockers to the latest
> release I feel like that kind of issue isn't necessarily touched by
> moving to a shorter release cadence. In fact if we're unwilling to let
> certain fixes wait a release then it exacerbates the risk of slowing
> down a release. I'm not really sure what to do about this, other than
> adopting the mentality that fixes might not make the major release and
> will have to come in a point upgrade if they can't be merged to the
> release branch in time. 
> 
> Regarding the benefits of an abbreviated release cycle, we see it quite
> a lot in the rust community. There's a good amount of community
> involvement with the new releases, and new features are hotly
> anticipated as they often occur on a timescale where the enthusiasm is
> still there. I also feel, though this is purely anecdotal, that the more
> agile release schedule encourages community contributions as the
> tangible benefits of contributor work can be realised much more quickly.
> The number of RFCs in discussion at the moment is evidence of that, I feel. 

(Sorry, this is also kind of a braindump.)

I'd like to add a few thoughs (or just to underscore the ones you've
already brought forth, as the case may be):

- In the case of e.g. the Linux kernel, there's a pretty good assurance
that *someone* will maintain a "stable" release of a reasonably-recent
version of the kernel and backport(!) patches for, say, up to a year
(either distros or the 'stable' kernel maintainer & co). In the case of
the Linux kernel backporting will *usually* not be that much work, but
in the case of GHC it *might* be a lot more work for any number of
reasons -- I wouldn't presume to know. Also note that this is
*basically* how Rust also works, it's just that they keep the "unstable"
bits behind a feature flag (until they're deemed 'stable') instead of
actually having different code bases.

- Releasing often means that *all* the upstreams who care(!) get to
"start" early as well. (RCs notwithstanding) See e.g. Stackage.

- Releasing often means that any serious bugs that get into a release
can also get a *release* that fixes them ASAP (and this is important:)
*independent* of any other release-blocking bugs in *upcoming* features.
This is a Big Deal(TM) and I think it's why the Linux kernel model works
at all.

- Releasing often means that there isn't this absolutely mad rush to get
$YOUR_FEATURE in before the deadline, because what's another 3/6 months
in the grand scheme of things? When you don't know if $FEATURE will make
it in in ½ year or 2 years, then it's a problem -- and you rush like mad
(likely making miskakes in the process).

- As a corollary to that: It is *paramount* that the release schedule is
adhered to *quite* strictly. This is also, I believe, key to its success
in the Linux kernel and Rust community. It doesn't matter much if
feature "X" makes it in -- it'll be in the next soon-to-come release.

- And, yes, this means a serious committment to improving the
tooling/automation around GHC releases.

Regards,