Re: [GHC DevOps Group] Release policies

Gershom B writes: > This proposal seems to have trailed off. I think it is worth putting a bow > on it and getting it signed off on for the GHC release policy page. > Yes, thanks for reviving this. I agree; we should wrap this up. > Let me restate it: > > > Bundled library

Re: [GHC DevOps Group] Release policies

This proposal seems to have trailed off. I think it is worth putting a bow on it and getting it signed off on for the GHC release policy page. Let me restate it: Bundled library maintainers agree to the following responsibilities: 1) When GHC cuts a feature-freeze branch, they too (if anything

Re: [GHC DevOps Group] Release policies

On December 19, 2017 at 8:15:49 PM, Manuel M T Chakravarty (c...@justtesting.org) wrote: > > > This in particular implies that everything merged to the release > branch has to have been well tested (the wiki page states, ”[o]nly > previously agreed on, stable and tested new functionality is >

Re: [GHC DevOps Group] Release policies

Thanks for the terminology clarification, Gershom. As a general note, adding features or completing hitherto incomplete features on the release branch is something that should be avoided as much as possible. For starters, it is generally more work than doing it before the release branch is cut

Re: [GHC DevOps Group] Release policies

Thanks for spelling this out Gershom. Reading it through, here are my questions: 1. What's the definition of "feature freeze"? Does it mean API stability? Does it mean not code changes at all except to fix a bug? Are performance fixes allowed in that case? 2. What's the minimum time between GHC

RE: [GHC DevOps Group] Release policies

December 2017 10:16 | To: Gershom Bazerman <gersh...@gmail.com>; Simon Peyton Jones | <simo...@microsoft.com> | Cc: ghc-devs <ghc-devs@haskell.org>; ghc-devops-gr...@haskell.org | Subject: Re: [GHC DevOps Group] Release policies | | I believe the standard policy would be to say th

Re: [GHC DevOps Group] Release policies

I believe the standard policy would be to say that even master may only dependent on released versions of dependencies. That is after all the only way to have a master that is always ready to be cut for a release (as per modern CI practices). Given the tight coupling of some of the

Re: [GHC DevOps Group] Release policies

Let me try to formulate a synthetic policy as per Simon's request: Policy: Bundled library maintainers agree to the following: 1) When GHC cuts a feature-freeze branch, they too (if anything has changed) cut a feature-freeze branch within two weeks at the maximum (ideally sooner), to be

Re: [GHC DevOps Group] Release policies

Hi Herbert, On 18 December 2017 at 12:22, Herbert Valerio Riedel wrote: > Hi Mathieu, > > On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu wrote: >> it's worth thinking about asking that >> the versions of all upstream packages only make it into GHC, at

Re: [GHC DevOps Group] Release policies

Hi, this might only be tangentially relevant. However, you might consider this a working example of GHC and Cabal bleeding edge symbiosis. Some might have seen that I built some *relocatable* GHC releases for cross compilation (however those include the full base compiler for macOS and linux

RE: [GHC DevOps Group] Release policies

[mailto:ghc-devops-group-boun...@haskell.org] On | Behalf Of Boespflug, Mathieu | Sent: 18 December 2017 11:03 | To: Manuel M T Chakravarty <manuel.chakrava...@tweag.io> | Cc: ghc-devops-gr...@haskell.org; ghc-devs@haskell.org Devs | Subject: Re: [GHC DevOps Group] Release policies | | I

Re: [GHC DevOps Group] Release policies

I think Mikhail's point is that if a package says build-type: Simple, then we know exactly what its Setup.hs says, and therefore also which part of the Cabal API it's using. Easy enough to keep that part stable even if others change. Case in point: Cabal-2.0 brought a number of changes to the