GHC release timing and future build infrastructure

[Ben Gamari]

Ara Adkins <me at ara.io> writes:

> 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.
>
You are to some extent correct; an unwillingness to release before major
(for some definition of "major") bugs are fixed will inevitably lead to
slips. However, I think a faster release cycle will make it easier to
accept releases with such bugs (at least in the case of non-regressions).

> 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.
>
> It's not all sunny, however, as having so many rapid releases means
> that it's sometimes difficult to rally the community around certain
> releases and feature sets. This is perhaps less of an issue due to the
> maturity of GHC and its ecosystem, but, like you say, it's important
> to find a good trade-off between release cadence and stability.
>
> Personally, I think Rust's cadence is a touch too short. On a related
> note, there's a 'checkpoints' initiative to build rallying releases
> that represent significant milestones in development [1]. This is,
> however, also tied into Rust's stability story, so only parts of it
> are relevant to GHC.
>
I agree that Rust is a bit extreme. Even with ideal tooling I don't
think that GHC could manage the cadence maintained by Rust, nor do I
think we should. The language is simply at a much different point in its
evolution. Their strong adherence to stability certainly also helps.

> In terms of automated tooling, I think there is significant benefit
> from it. Again, using rust as an example, there is cargobomb [2], a
> significant automated testing initiative that both combines packages
> on Cargo, and runs their test suites. I feel that a combination of the
> Stackage LTS and Nightly releases would provide a well-curated subset
> of Hackage that could possibly be used in a similar fashion. This hits
> on your item (b).
>
> Regarding your questions:
> - In comparison to rust it can feel like there's significant delay in
>   being able to really use GHC's newest features. I feel like this delay
>   can hinder adoption of the features as much of the enthusiasm for them
>   has died down by the time they're properly available.
>
This seems to be a pretty widely held belief. It is very helpful to hear
this clearly articulated.

> - With the advent of tools such as `stack`, the compiler upgrade
>   process has almost become trivial. While not everyone uses it, it
>   requires no more work than upgrading to a new LTS release and running
>   `stack setup`. Nevertheless, I could imagine four upgrades a year
>   still being okay if it was manual.

Indeed tools have improved remarkably in the Haskell community over the
past few years. However, I feel like a word like "trivial" may be a bit
strong here. Afterall, library authors still need to follow changes in
core libraries (e.g. template-haskell, ghc-prim, and ghc itself). This
does require effort, although perhaps on the part of a smaller number of
people.

> - The three release policy is an interesting case as the question of
>   changing it really comes down to how we view the GHC stability story.
>   Personally, I think we want to target a time-period of stability,
>   rather than a number of releases. Whether that time period is 1.5
>   years (assuming a six-month release cadence), or 3 years (rounding the
>   current release cadence) seems like a totally independent discussion
>   to me.

This makes sense.

> - I think I've covered incentives to contribute in my discussion of
>   Rust above.
>
> I hope that's useful! 

Indeed it is. Thanks for taking the time to share!

Cheers,

- Ben

-------------- 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-devs/attachments/20170802/ff1f85bd/attachment.sig>