Re: Can't push to haddock

2017-12-19 12:47 GMT+01:00 Phyx : > Cool, then let's turn to media reports then such as > https://techcrunch.com/2017/07/31/github-goes-down-and-takes-developer- > productivity-with-it/ do you have one for git.haskell.org going down? Of course this question is a classic

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: Can't push to haddock

On Tue, Dec 19, 2017 at 4:30 AM, Sven Panne wrote: > I think this is a question of perspective: Having the master repository on > GitHub doesn't mean you are in immediate danger or lose your "family > jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that >

Re: Can't push to haddock

> You're also assuming github doesn't suddenly pull a SourceForge (or a > Gitorious for that matter). Business cares not what it steamrolls in the > name of profit. > > I fail to understand why, with multiple examples of the folly of this > belief out there, people are still willing to bet on

ghc-prim 0.5.1.1 not on Hackage

The Stackage issue tracker just received an issue about ghc-prim 0.5.1.1. https://github.com/fpco/stackage/issues/3115 This version of the package has not been uploaded to Hackage, so: * The Stackage snapshots refer to 0.5.1.1 * The stackage.org documentation shows version 0.5.1.1 * `stack

Re: Can't push to haddock

Thank you for that word of reason. (In addition to your very well stated point, the whole point of Git is that it is a *distributed* RCS. I don’t think, anything less than a full scale planetary nuclear war could really wipe out the GHC source code at this point.) Manuel > 20.12.2017 05:02

Re: Can't push to haddock

I think, what Sven is getting at here —and I do have to say, I concur— is that there is a bit of NIH (Not Invented Here) syndrome in parts of the Haskell community. I think, part of it is just inertia and the desire to keep things the same, because that is easier and more familiar. One aspect

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: Can't push to haddock

Hi, On 2017-12-19 at 08:31:06 +0100, Sven Panne wrote: > This is a tradeoff: Doing it that way, you catch incorrect commits a > little bit later, but it makes the overall arcane repository magic > quite a bit simpler, probably removing the need for mirroring. We'd need mirroring anyway, as we

Re: Can't push to haddock

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel : > We'd need mirroring anyway, as we want to keep control over our > infrastructure and not have to trust a 3rd party infrastructure to > safely handle our family jewels: GHC's source tree. > I think this is a question of

RE: Can't push to haddock

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special. Speaking for myself, I have no hostility towards GitHub, and there is no GHC-HQ bias

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

| 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

Re: Can't push to haddock

2017-12-19 11:07 GMT+01:00 Phyx : > These are just a few of the times github has been down in 2017 > http://currentlydown.com/github.com compared to haskell.org http:// > currentlydown.com/haskell.org [...] > I can't see any data for haskell.org on that page, apart from the