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,