Broken master branch. Who brings cake?

[kikofernandez]

Hi,

am I the only one having troubles to compile the current master branch? I keep getting this error:

src/types/Types.hs:95:10:
    Not in scope: type constructor or class ‘Foldable’

can anyone confirm?

[EliasC]

Did you update to GHC 7.10? I think there was a change in what is included in the Prelude for that version. I run GHC 7.10.2.

[kikofernandez]

Yes, I can confirm! Some of us were still using ghc-7.8.3 or ghc-7.8.4 (released 30th March 2015). Some others have installed the latest version (29th July 2015). This latest version breaks compatibility with prior versions (release note, specially the "Burning Bridges Proposal" which bit us). We need to be more careful when doing this... who is going to bring cake?

[kikofernandez]

Not to repeat myself but, because of this update (last PR merged), everyone using Encore has to update to the latest ghc version. For some savvy engineers like us :) , that's probably just a breeze. For some others, specially partners and/or students, it might not be that simple

[supercooldave]

I think we should avoid being too bleeding edge these days, as we have quite a lot of customers.

[EliasC]

How hard would it be to start providing binaries?

[supercooldave]

Cake binaries?

[EliasC]

Re: cake. It was @albertnetymk's PR, but I was the one who merged it. According to ourselves

We're using:

• ghc: The Glorious Glasgow Haskell Compilation System, version 7.6.3

which isn't true in practice either (@kikofernandez confessed using 7.8.3 or 7.8.4). I would like to avoid having several GHC versions installed in order to test backward compatibility.

[EliasC]

Related: There are two obvious ways of fixing this:

1. Everyone updates to >= 7.10.1 (and we update our requirements)
2. We fix the code so that it works with the older versions as well.

I'm biased, having upgraded myself, but since GHC will likely keep updating we might as well "cross the burned bridge". Of course, we should be wary about future updates!

[kikofernandez]

I would opt for 1, since master is already broken. If we are going to "Burn bridges", this is our chance

[kikofernandez]

there's already a PR that forces everyone to use ghc-7.10.2

[albertnetymk]

I think the CI says the PR is OK, so it's merged. Each of us has different setup, which is why we have CI to reach the agreement whether master builds or not.

[EliasC]

So everyone should start building every PR just to see if something is broken? Is that really realistic?

[kikofernandez]

@albertnetymk ummm... that argument is a bit flawed... so, we rely on something that no one but me has access... which doesn't always work correctly (tobias forgot to include a header file for the ranges and the CI didn't complain)... I think the CI is good to have and we can get some kind of QA but it definitely does not rule over us

[EliasC]

Since I am the merger, I will bring cake for the next meeting! (I also happen to like cake)

Is the meeting next Friday?

[albertnetymk]

So everyone should start building every PR just to see if something is broken? Is that really realistic?

Is this question for me? If so, then which is why we have CI, isn't it?

Who has the access to the CI isn't the point here. CI, as one system, of course could encounter problems, but we would fix them as soon as we found it. Using the customized CI is merely a compromise currently; once the repo goes public, dedicated CI could be used.

One key advantage offered by CI is build and tests are run in a strictly defined env, which is impractical on developers' machine.

[EliasC]

I thought CI was the process of checking PRs, but you're talking about Jenkins it seems. If so, my comment is void! I'm not familiar with the terminology.

[kikofernandez]

yes, @albertnetymk means that whenever we create a PR, Jenkins tests the PR and that's why you see the green logo on the PR. If there's something broken you'll see a red X. Jenkins tests every PR and every commit into master but it seems like it's a bit broken...

[albertnetymk]

Jenkins tests every PR and every commit into master but it seems like it's a bit broken...

This is a much serious problem, in my opinion. How so?

[kikofernandez]

I don't know... I would need to go through the logs... as soon as I know more I'll post it

[albertnetymk]

I thought CI was the process of checking PRs

Yes, it contains that and sth else. More on CI, if you are interested.

[kikofernandez]

@albertnetymk, the much serious problem with the CI is fixed now! We can all sleep at night at last!

[albertnetymk]

What's the cause?

[kikofernandez]

one of the errors was done when parsing the output from make test. I was looking for the word error to throw an error. trying to run with ghc-7.8.3 throws a failure not an error and therefore it was not marked as an error.

[EliasC]

@kikofernandez Would it be possible to look at the return value of running make test? That should be more reliable (and resilient to change).

[kikofernandez]

Yes, I think that's possible. I was trying to trim all the output from make test and leave only the part where it says:

Tests passed: 72/72
Tests failed: 0/72

[supercooldave]

Not that now (and more so in the future) the tests are broken into different parts. Currently there is "all" and "modules". It would be good if, at least, the results were broken down into the various parts.

What about displaying the failing tests?
... succeeding tests?
What about a verbose mode that displays all?