| PS: Simon, I am sorry, but IMHO it is too early for a summary and policy
| proposal as the discussion hasn’t really converged yet. In any case, I am
| happy to write a summary Trac page once we are there. Is that ok?
Yes, I'm perfectly happy with that, thank you. I just wanted to be sure that the discussion eventually converged rather than petering out.
Many thanks to Gershom for putting out a concrete suggestion; I think that concrete proposals can help to focus a debate.
Simon
| -----Original Message-----
| From: Manuel M T Chakravarty [mailto:chak@justtesting.org]
| Sent: 19 December 2017 10:16
| To: Gershom Bazerman ; Simon Peyton Jones
|
| Cc: ghc-devs ; ghc-devops-group@haskell.org
| Subject: 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 dependencies of GHC with GHC,
| maybe we need to consider something weaker, but I think, the weakest
| reasonable (from a CI standpoint) policy is to say that, while master may
| depend on pre-release versions, release branches can *only* depend on
| released dependencies. In other words, a release branch can only be cut
| when master has progressed to a point where it only depends on released
| versions of its dependencies.
|
| Under that compromise, cutting a GHC release branch may be delayed by a
| delayed upstream release, but hopefully the approx 3 month release
| process has enough slack to tolerate that. (It is obviously not ideal,
| though.)
|
| Cheers,
| Manuel
|
| PS: Simon, I am sorry, but IMHO it is too early for a summary and policy
| proposal as the discussion hasn’t really converged yet. In any case, I am
| happy to write a summary Trac page once we are there. Is that ok?
|
| > 19.12.2017 06:41 Gershom B :
| >
| > 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 included in the main GHC freeze branch. If
| > they do not do so, the last released version will be included instead.
| > 2) When GHC releases the first release candidate, maintainers (if
| > anything has changed) release new versions of their packages, to then
| > be depended on directly in the GHC repo. All submodules are then
| > replaced with their proper released versions for GHC release.
| >
| > This policy can be enforced by GHC hq as part of the release process
| > with the exception of a case in which there's coupling so that a new
| > GHC _requires_ a new submodule release, and also the maintainer is not
| > responsive. We'll have to deal with that case directly, likely by just
| > appealing to the libraries committee or something to force a new
| > release :-)
| >
| > Motivation:
| > This should help address multiple issues: 1) holdup of ghc on other
| > releases. 2) lack of synchronization with ghc and other releases. 3)
| > low lead-time for people to adapt to API changes in forthcoming
| > library releases tied to ghc releases. In particular, because Cabal is
| > part of this policy, it should help circumvent the sorts of problems
| > that led to this thread initially. Further, because this only applies
| > to freeze/release branches, it should not slow down
| > rapid-implementation of cross-cutting changes more generally.
| >
| > Cheers,
| > Gershom
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
