@pocmatos I think even if AppVeyor is currently testing something different than Actions, we should get rid of it now and think about expanding platform coverage later subsequently.

@samth I am looking at this.

I think AppVeyor work is already covered by CI PR but not by CI Push. Although we run on a more recent VS installation. Appveyor on VS2012 and Actions in VS2019

I thought we did everything on Push that we did on PR? Or did you mean that the other way around?

And we probably care about VS2012 as well, but I don’t know that we care enough to run CI for it.

https://github.com/racket/racket/pull/2949

Everything on PR is on Push except windows testing. Coming later on this evening.

Ah, ok.

Do we care specifically for VS2012? Or do we just care for all version since 2012?

Since I don’t use Windows at all, I am a bit lost as to what to test here (or even how to test specific VS versions).

Well, probably (a) we care generally about “older things” but without a specific policy and (b) VS2012 support implies it will work for later ones in “most” cases

OK - Maybe we can try to add support for 2012 as well (on an upcoming nightly CI doing also emulation) and on push and pr test keep testing only 2019. What do you think?

That seems good to me. It might be worth trying to write down (in the new “build guide” @mflatt wrote) what systems/compilers are supported.

Yes - I was actually going to update later on this page: https://github.com/racket/racket/wiki/Continuous-Integration

I will add a summarized version to the build guide as well - it makes sense.

By the way, do you know why we keep libffi in repo, given it’s something that the user can easily install? It would be better not to have these external deps in repo, as it create weak points in our code. Things like upstream bug fixes are not reflected in repo, etc. Also, makes me think we should test racket with upstream libffi and inrepo libffi, to cover our basis - however this will really increase the total number of jobs.

I think there are some patches, and it makes it easier to build Racket (esp on platforms like Windows)

Argh… feel like cursing Windows. OK.

I think even on MacOS it’s not as easy to install build dependencies

I disabled AppVeyor as well

Thanks.

I have a busy day today but I will look at this again in the evening. Talk to you later.

@pocmatos one other thing — we have our quarterly Racket Core meeting today (I’m actually at the airport right now). Anything CI (or not-CI) related I should bring up?

Yes - thanks for asking.

I think it is important for the long term Racket project stability (which is directly related to CI) to be clear about what platform configurations (OS/Compilers/Compiler versions/Machine Architectures) we support.

Of course, I can come up with a list (mostly it will be the things that I can test) but I think it would be ideal for the core team to say something like “I think it is important for us to support this list of configurations.” Doesn’t need to be straightaway but it would be important to have.

This could drive not only CI but also future patches.

There have been situations where patches were refactored because we want to support platforms that are impossible for us to test QNX. From a CI perspective this is suboptimal because from a CI pov - if it’s not tested, it doesn’t work. (or it will stop working soon).

Also, patches that were changed because we need to support ANSI C or an old GCC.

I think for CI sake and the sake of contributors (current and future ones) we need to have a set of platforms we support and that needs to be decided or at least approved by the core team.

Again, I can come up with a proposal if the core team has better things to think about, but it should be approved and agreed with the core team.

A good start if for the core team to look at rktio_platform.h

Do we want to say we support all of that?

If so, then we need to think how to test that.

If not, lets write down what we support and remove it from the code base.

Have a safe journey.

Thanks. I’ll bring this up. With that said, I’m pretty sure that Matthew will say the following: A list of currently-known supported platforms is a good idea, and he’ll volunteer to add that to the build guide. We (= you and me) should add something about tested platforms there as well. But he won’t want to remove code because even if it doesn’t work currently (likely, as you say) it contains useful knowledge about what it would take to fix that platform (such as QNX). Except in the case of platforms that we’re confident we don’t plan to support in the future (such as Windows XP, I think).

Understood. I am not sure I fully understand his point of view on keeping code which is mostly likely broken given that with source code revision we can always go back in time to see how we did QNX (or others) if we ever need to support them again. Hopefully one day we’ll have the opportunity to discuss this face-to-face. Some things tend to get lost when discussions happen over the wire so I might be missing something important.

Come to RacketCon in the fall!

In any case, your proposal of having a core team supported platforms list and a tested plaforms list is great. I would like prefer if they are both one and the same - the CI dream. :-)

Also, hopefully several people will be at PLDI in London this year

I will come to RacketCon this year - yes.

as in 2020

submit a talk!

Sure! Who should I submit it to?

The call will happen in a few months, so you have a while :slightly_smiling_face:

Ah - fair enough. :slightly_smiling_face:

@samth appveyor needs to be disabled somewhere: https://ci.appveyor.com/project/plt/racket/builds/29247024

That happened before I disabled it

Ah ! Thanks