On Mon, Oct 14, 2013 at 3:42 PM, Joachim Breitner wrote:

Hi,

Am Sonntag, den 13.10.2013, 17:50 +0200 schrieb Michael Snoyman:

...

I wanted to announce that FP Complete is now running a Jenkins job to build Stackage with GHC 7.8. You can see the current results in the relevant Github issue[1]. Essentially, we're still trying to get version bounds updated so that a build can commence.

Great!

Is there a way to view the jenkins build results somewhere?

For some reason I miss a proper homepage of stackage with links to all the various resources (but maybe I’m blind).

No, you're not blind, I just haven't gotten things set up in that manner yet. Specifically for GHC 7.8, there's nothing to display. Until a pull request on HTTP is merge[1], there's nothing to show at all from the Jenkins builds. But once that's done, it would be hard to display the Jenkins results, since I run half the jobs from my local system, and then the other half from the FP Complete build server. If anyone has experience with publishing Jenkin's build reports from two different systems and wouldn't mind helping me out, please be in touch, it would be nice to get the information available in a more publicly-accessible manner. Michael [1] https://github.com/haskell/HTTP/pull/47

I'm not aware of any binary snapshot available. I generally don't build GHC from source either, but did so to start this set of testing. On Mon, Oct 14, 2013 at 9:23 PM, Sebastiaan Visser wrote:

Michael,

I see one of my packages is on that list, because of the upper bound on template-haskell. I would love the raise the upper bound, but of course only if it will actually build.

Can I download a binary version snapshot GHC 7.8 somewhere so I can test and apply changes accordingly? I actively avoid building GHC from source.

Thanks, Sebastiaan

On Oct 13, 2013, at 5:50 PM, Michael Snoyman wrote:

...

Hi everyone,

I wanted to announce that FP Complete is now running a Jenkins job to build Stackage with GHC 7.8. You can see the current results in the relevant Github issue[1]. Essentially, we're still trying to get version bounds updated so that a build can commence.

I'd like to ask two things from the community:

* If you have a package with a restrictive upper bound, now's a good time to start testing that package with GHC 7.8 and relaxing those upper bounds. It would be great if, when GHC 7.8 is released, a large percentage of Hackage already compiled with it. * If you have a package on Hackage that is not yet on Stackage, now's a great time to add it. We're going to be doing daily builds against three versions of GHC (7.4.2, 7.6.3, and 7.8), which will help ensure your packages continue to build consistently.

Michael

[1] https://github.com/fpco/stackage/issues/128

On Wed, Oct 16, 2013 at 8:34 AM, Magnus Therning wrote:

On Tue, Oct 15, 2013 at 10:29:38AM +0200, Michael Snoyman wrote:

...

I'm not aware of any binary snapshot available. I generally don't build GHC from source either, but did so to start this set of testing.

Are you all pulling out the source from VCS (Git or whatever is used nowadays)?

I've been looking for tar-balls of RCs or daily snapshots, but all I've found is [1], which seems to not hold anything recent.

Yes, I just built from Git. Michael

On Wed, Oct 16, 2013 at 8:53 AM, Carter Schonwald wrote:

indeed, its really easy to build HEAD from source! (heck, i even built a copy of HEAD with a custom prelude this afternoon for some experimentation! :) )

Very good to hear, then I can start preparing Arch Linux for the release already :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On Sat, Oct 19, 2013 at 9:31 AM, Ketil Malde wrote:

Michael Snoyman writes:

...

* If you have a package with a restrictive upper bound, now's a good time to start testing that package with GHC 7.8 and relaxing those upper bounds. It would be great if, when GHC 7.8 is released, a large percentage of Hackage already compiled with it.

The biggest problem with upper bounds (or not), is that frequently, somebody will update a package that requires a bleeding edge GHC. I, on the other hand, often need to install software on older systems (last time was Fedora 17, more than a year old, and shipping GHC 7.0.4). Needless to say, central packages like template-haskell, array, stringable, and happy all fail to compile, and then I try to manually install older and older versions of these packages, until one of them finally works. This is time consuming and cumbersome, and while I can do it, I clearly cannot inflict this on my users.

(And some systems I have to work with - typically "enterprise" distributions - ship with even older GHC versions, but then I typically compile GHC from source.)

IIUC, what you're pointing out isn't really about upper bounds, but about the lack of backwards compatibility with GHC core packages. I couldn't agree more with this sentiment. I highly encourage maintainers to use Cabal CPP macros to ensure that their code compiles with the widest range of dependencies, *especially* core packages. containers is probably the biggest problem here, where I've many times seen some code import Data.Map.Strict and thereby exclude older versions of containers, when a simple CPP macro would have fixed the problem.

...

* If you have a package on Hackage that is not yet on Stackage, now's a great time to add it.

I'd love to, what do I need to do?

There's a maintainer's agreement available at: https://github.com/fpco/stackage/wiki/Maintainers-Agreement I'm considering making a simplifying modification to this agreement: if you want to include a package, but haven't tested it against Stackage, feel free to just send me a pull request with the addition, and just make sure to comment that you haven't tested it yet. I don't mind being your first line of compatibility checking here, as I know that running a full Stackage build can be a time-consuming process.

...

We're going to be doing daily builds against three versions of GHC (7.4.2, 7.6.3, and 7.8), which will help ensure your packages continue to build consistently.

This is great, any chance of including yet older compilers? The sad fact of life is that people use "enterprise" and "LTS" distributions, which inevitably means outdated software..

Unfortunately, it's doubtful. I'm hopeful that moving forward, Stackage can encourage maintainers to continue supporting GHC 7.4.2 for longer than previous GHC releases have been supported. But I doubt there will be enough momentum to convince most package maintainers to start adding support for GHC 7.0 or 7.2, both of which are over two years old. I'd love to see a GHC version supported for more than two years, but it's very difficult to add those fixes in after the fact. Nonetheless, I'm downloading GHC 7.0.4 right now, I'll see if I can try to get a build going, but if my intuition is correct, the number of failures will be too high to even attempt addressing them. Michael