2014-07-07 3:40 GMT+02:00 William Knop :
> I think using Jenkins may be a step in the right direction for a few reasons:
[..]
> Now, I don’t have much experience with buildbots, so I may be unfairly
> elevating Jenkins here. If buildbots can be easily extended to do exactly what
> we need, I’m all
On 2014-07-07 at 03:40:17 +0200, William Knop wrote:
[...]
> I think using Jenkins may be a step in the right direction for a few reasons:
>
> • there are hundreds of supported plugins [1] which cover notifications, code
> review [2], cloud computing services, and so on
> • there is quite a lot
Hi again,
I think I may have been too brief in my reply. To recap previous discussion, it
seems there are a few pieces which can be approached separately:
1) arbitrary/discretionary cross compilation
2) continuous integration for all patchsets
3) nightly builds
The first, as has been pointed ou
Hi Pali,
Apologies for the delayed response.
I treated cloud compilation as “free” in the context of the buildbots. If we
can cross-compile (on Amazon EC2 or the like) ghcs which run on each arch we
have for buildbots, the buildbots themselves will have 1/5 the load. I came to
that figure from
Hi Pali and all,
Sorry for the delayed replies; a bunch of things came up and I probably won’t
be able to respond properly for two days or so. I am very interested in
progressing with this as soon as I can. Many apologies!
Will
On Jun 20, 2014, at 6:15 AM, Páli Gábor János wrote:
> Hello Wi
Hello William,
2014-06-20 0:50 GMT+02:00 William Knop :
> 1. We have a pretty good spread of buildbots, but as far as I know there
> aren’t
> very many of them. Running only the test suite would increase their utility by
> roughly 5x (from looking at the buildbot time breakdowns [1]).
How would
I thought Alain already replied? He and Pali are running some ghc-builder
boxes, and i'm helping with code review for patches into ghc-builder
On Fri, Jun 20, 2014 at 3:10 AM, Simon Peyton Jones
wrote:
>
> | This response has gotten pretty long! Apologies if I missed something,
> | or otherwise
| This response has gotten pretty long! Apologies if I missed something,
| or otherwise misunderstood. Anyway, if there's a path here that seems
| sensible, I'll have a go at it.
William, I am not qualified to comment on the details, but thank you for
offering to help. I do urge you to pick so
Hi Austin,
Thank you for the quick and thorough reply! There are a lot of points to cover,
so I’ll respond in a few sections.
*** The CI Scheme
I realize the vast majority of the work would be in #1, but just want to
highlight the idea that there is a real benefit to be had. To address the
2014-06-19 1:53 GMT+02:00 Austin Seipp :
> We actually already do have both of these already, too: Joachim
> Breitner for example has set us up a Travis-CI[1] setup, while Gabor
> Pali has set us up nightly builds[2]. Travis-CI does the job of fast
> CI, but it's not good for a few reasons:
[..]
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Great and detailed response Austin. Thank you.
William, I'm happy to help in any way I can.
I run SmartOS x86 and x86_64 builds of GHC HEAD on my own equipment
using the GHC Builder Ian Lynagh developed:
https://ghc.haskell.org/trac/ghc/wiki/Builder
Hi William,
Thanks for the email. Here're some things to consider.
For one, cross compilation is a hot topic, but it is going to be a
rather large amount of work to fix and it won't be easy. The primary
problem is that we need to make Template Haskell cross-compile, but in
general this is nontriv
Hello all,
I’ve seen quite a few comments on the list and elsewhere lamenting the time it
takes to compile and validate ghc. It’s troublesome not only because it’s
inconvenient, but, more seriously, people are holding off on sending patches in
which stifles development. I would like to propose
13 matches
Mail list logo
