Please include the reduction-effects plugin in the standard install about platform

[Zimmi48]

The reasons that pushed for this to be done as an external plugin were kind of dubious from the beginning, as this was not the choice of the author of the plugin, makes discoverability harder, etc. The experimental nature of the thing could instead be flagged as proposed in coq/coq#9664.

Furthermore, the author is not used to having to maintain external plugins, and similarly to Bignums, we end up with everyone forgetting to update the opam package, etc.

I see two possible routes for these two plugins: either they get back into the main repo (this could be under an external/ folder, which would be tested in CI in the same way that external plugins are tested, with specific opam files, etc.) or they move to coq-community. The Coq development team has no business maintaining a large diversity of packages spread out over multiple repositories.

[gares]

I think the simplest thing today is to have it part of coq-comunity, since the external/ thing is not a thing yet, while coq-community is.

[Zimmi48]

Right. @JasonGross Would you like to be the plugin's principal maintainer in coq-community? Given that we can also add it to Coq's CI at the same time (as you suggested), this will mostly consist in handling incoming PRs, and preparing new compatibility releases every six months.

[Zimmi48]

(and we can keep this issue open until it is added to the Windows bundle)

[JasonGross]

Sure, I am fine with handling incoming PRs and branching / tagging / updating opam or whatever as necessary, every six months, as long as someone tells me what needs to be done the first time. (I will probably write a script that executes the "prepare compatibility release" steps.)

[Zimmi48]

I will probably write a script that executes the "prepare compatibility release" steps.

See also coq-community/manifesto#49.

[Zimmi48]

This plugin is now hosted in coq-community: https://github.com/coq-community/reduction-effects
Before it can be added to Coq's CI, it will need to be ported to Coq 8.9-8.11.

[liyishuai]

• master branch is now tested with Coq 8.10, 8.11 and dev.
• v0.1.2 supports Coq 8.10 and 8.11 (and current dev).
• v0.1.1 supports Coq 8.9.
• v0.1.0 supports Coq 8.8.

[JasonGross]

Note that it's been in the Coq's CI since coq/coq#11469. Now we just need to get it included in the installer.

[JasonGross]

cc @MSoegtropIMC , I think

[MSoegtropIMC]

OK, I will add it.

[Zimmi48]

@MSoegtropIMC I can also address this if you don't have time.

[MSoegtropIMC]

It would help, yes.

[MSoegtropIMC]

Btw.: my plan is to deliver a Coq platform based Windows installer for 8.12 in the intended timeframe (1..3 months after the 8.12 release - it will likely be less than 2 months). I also plan to deliver a beta for 8.12 beta. So I don't know if it is required to add this to the 8.12 legacy Windows installer. I am currently concentrating on getting the dependency wise complicated pieces of the platform pulled straight (VST and CompCert).

[Zimmi48]

Let's delay this issue to the platform. We can always decide to add it in a patch-level release of Coq if the platform work hasn't progressed as much as expected.

[MSoegtropIMC]

Sorry for the really long delay. I now included it in the 8.132021.09 pick and plan to include it in 8.142021.09 as well. But since it is a 0.X version, I added it to the extended set - hope this is OK.

I tested the one provided test file and it appears to work.

[MSoegtropIMC]

Fixed in #143