GHC release timing and future build infrastructure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GHC release timing and future build infrastructure

Ben Gamari-3

Hello everyone,

I just posted a pair of posts on the GHC blog [1,2] laying out some
thoughts on the GHC release cycle timing [1] and how this relates to the
in-progress Jenkins build infrastructure [2]. When you have a some time
feel free to give them a read and comment (either here or on the Reddit
thread [3]).

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
[2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci
[3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Ara Adkins
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. 

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. 

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. 
- 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. 
- 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. 
- I think I've covered incentives to contribute in my discussion of Rust above. 

I hope that's useful! 

Best,
_ara


On 1 Aug 2017, at 03:19, Ben Gamari <[hidden email]> wrote:


Hello everyone,

I just posted a pair of posts on the GHC blog [1,2] laying out some
thoughts on the GHC release cycle timing [1] and how this relates to the
in-progress Jenkins build infrastructure [2]. When you have a some time
feel free to give them a read and comment (either here or on the Reddit
thread [3]).

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
[2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci
[3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Brandon Allbery
In reply to this post by Ben Gamari-3
On Mon, Jul 31, 2017 at 10:19 PM, Ben Gamari <[hidden email]> wrote:
I just posted a pair of posts on the GHC blog [1,2] laying out some
thoughts on the GHC release cycle timing [1] and how this relates to the
in-progress Jenkins build infrastructure [2]. When you have a some time
feel free to give them a read and comment (either here or on the Reddit
thread [3]).

This release was actually a bit unusual for recent releases, in that a significant delay did *not* come from working around a major breaking behavior change in a Tier 1 platform; recent examples being macOS's load commands limit and Ubuntu defaulting to position-independent executables.

I think this might be relevant to the question of slipping extra stuff into releases: it's become so common to have extra time courtesy of Tier 1 platforms breaking things on us that slipping extra stuff in is now expected.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Ben Gamari-3
In reply to this post by Ara Adkins
Ara Adkins <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Bardur Arantsson-2
In reply to this post by Ara Adkins
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,

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Michal Terepeta
In reply to this post by Ben Gamari-3
On Tue, Aug 1, 2017 at 4:19 AM Ben Gamari <[hidden email]> wrote:

Hello everyone,

I just posted a pair of posts on the GHC blog [1,2] laying out some
thoughts on the GHC release cycle timing [1] and how this relates to the
in-progress Jenkins build infrastructure [2]. When you have a some time
feel free to give them a read and comment (either here or on the Reddit
thread [3]).

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
[2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci
[3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Hi Ben,

This sounds really cool! I'm pretty excited about more automation and
GHC releases more than once a year (maybe every 6 months?).

In my experience both automation and regular releases are a
significant win. They often result in more and quicker feedback, are
more motivating and make it easier to iterate/improve the project and
keep it in "releasable" state.

So thanks a lot for working on this! :)

Cheers,
Michal


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Bardur Arantsson-2
In reply to this post by Bardur Arantsson-2
On 2017-08-02 21:26, Bardur Arantsson wrote:

> I'd like to add a few thoughs (or just to underscore the ones you've
> already brought forth, as the case may be):
>
[--snip--]
> 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.
>

Sorry about the self-reply and excesive bolding-for-emphasis. The point
of this past paragraph was that *perhaps* GHC could move towards
(short-lived!) "feature flags" for the compiler[1]. Again, I have no
experience with the GHC development process so maybe it's completely
absurd to even contemplate such a thing (in terms of effort).

Continuing with the thought from [1]: What if there were "stability
tiers" of LANGUAGE PRAGMA? Obviously, it doesn't *literally* have to be
like that, but maybe the concept works?

[1] I suppose LANGUAGE Pragmas are *kind* of like feature flags, but IME
LANGUAGE Pragmas tend to be actually be quite long-lived.

Regards,

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Ben Gamari-2
Bardur Arantsson <[hidden email]> writes:

> On 2017-08-02 21:26, Bardur Arantsson wrote:
>
>> I'd like to add a few thoughs (or just to underscore the ones you've
>> already brought forth, as the case may be):
>>
> [--snip--]
>> 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.
>>
>
> Sorry about the self-reply and excesive bolding-for-emphasis. The point
> of this past paragraph was that *perhaps* GHC could move towards
> (short-lived!) "feature flags" for the compiler[1]. Again, I have no
> experience with the GHC development process so maybe it's completely
> absurd to even contemplate such a thing (in terms of effort).
>
It's not clear to me that this would work. Afterall, not all commits are
new features and, perhaps more importantly, not all bugs stem from new
features.

Rather, many of GHCs commits are in fact refactorings. This is one of
the major reasons why the codebase hasn't collapsed under its own weight
despite the last two decades of development. Sometimes these
refactorings are merely cleanups, sometimes they fix bugs, but sometimes
they also introduce bugs.

In principle, the role of a stable branch is to serve as a "known good"
state which we can place fixes that we are quite certain fix a bug
without knowingly introducing others. Of course, in part due to our long
release schedule, we have in practice been a bit more liberal in
backporting. That being said, I do fear that including all new commits, even
those that don't fix bugs, in all new releases may have the effect of
destabilizing those releases.

Of course, feel free to clarify if I've misunderstood the proposal
(which I fear I may have).

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Ara Adkins
In reply to this post by Ben Gamari-3
Glad I could provide some useful thoughts!

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).

I definitely agree that a shortened release cadence would help with the reduction of release blockers by making som things more acceptable. I think this would be one of the major benefits of shortening the release cycle.

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.

I'm definitely with you here. I think that a 3-month release cycle is the shortest that would work for GHC, but that would require a perfect set of tooling which we don't quite have yet. Your originally proposed six months sounds great to me, and I don't see an reason why it couldn't be altered further down the line if it wasn't quite working. 

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.

Trivial was perhaps somewhat overstating the current state of the ecosystem, yes. I nevertheless  see `stack` as a huge boon for easing adoption of new compiler versions (and hence new language features/extensions).

_ara

<snip>


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Herbert Valerio Riedel-3
Hi!

On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote:

[...]

> I nevertheless see `stack` as a huge boon for easing adoption of new
> compiler versions (and hence new language features/extensions).

Since I totally disagree about Stack being beneficial to the quick
adoption of new features, would you care to elaborate what makes you
think that Stack was a "huge boon" in this particular context?

Just to name one example where Stack has been lagging behind Cabal for
several months already: Support for Backpack or convenience libraries --
there's already a handful of packages on Hackage which Stack (and
consequently Stackage) cannot install due to this. Being slow to adopt
new features IMO makes totally sense for Stack, as it's target audience
is practicioners who value stability, "reproducibility" and "long term
support", so it's actually a good thing that Stack stays behind until we
iron out issues with new bleeding edge features and Stack(age) adopts
them only when they're officially released and deemed ready for Stack's
target audience.

-- hvr
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC release timing and future build infrastructure

Ara Adkins
I definitely agree with what you're saying around some of the features that require external support such as backpack. 

I think my statement was focused more on new language features that don't require additional support, as with stack getting access to those is as simple as hopping on the latest nightly release. 

On Thu, Aug 3, 2017 at 9:38 AM, Herbert Valerio Riedel <[hidden email]> wrote:
Hi!

On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote:

[...]

> I nevertheless see `stack` as a huge boon for easing adoption of new
> compiler versions (and hence new language features/extensions).

Since I totally disagree about Stack being beneficial to the quick
adoption of new features, would you care to elaborate what makes you
think that Stack was a "huge boon" in this particular context?

Just to name one example where Stack has been lagging behind Cabal for
several months already: Support for Backpack or convenience libraries --
there's already a handful of packages on Hackage which Stack (and
consequently Stackage) cannot install due to this. Being slow to adopt
new features IMO makes totally sense for Stack, as it's target audience
is practicioners who value stability, "reproducibility" and "long term
support", so it's actually a good thing that Stack stays behind until we
iron out issues with new bleeding edge features and Stack(age) adopts
them only when they're officially released and deemed ready for Stack's
target audience.

-- hvr


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Loading...