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 [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
