I would like to ask about the release cycle for this project.
I was checking the documentation, but I wasn't able to find any reference regarding this.
At this moment there is one commit for the GCC issue that wasn't released yet plus additional tests. And at least 2 issues created for the GCC problem.
What is the timing for this release?
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
@mattip, my best thought is linking this up as some kind of a "more complicated test case" for cibuildwheel and hoping Henry Schreiner would maybe find this interesting. He's managed to turn over CI and releases for pybind11, and made things a lot more workable.
The main issue is finding someone who might also have some kind of a stake in cffi, and some kind of a reason? Which (besides there not being any spare time left, currently) is also a reason why I don't want to promise taking up any duties, however amazing cffi is :-/
I'll nicely ask him, though. If you're happy with turning this into a complex cibuildwheel use case, there's a chance.
What's "complicated" here? I don't initially see anything scary, other than having to log into foss.heptapod :). I'm also not a Mercurial user. :( What CI would you be open to using / would be available here? Possibly this could help move Gitlab CI support forward, perhaps? We don't support Gitlab CI on Windows yet, and I don't remember if there was an open macOS runner. I couldn't do long-term maintenance because it's not a project that directly is needed by Scikit-HEP/IRIS-HEP, but I could possibly help set something up that would be open and easy to maintain, not depending on someone's laptop collection. I could probably scape a few hours in because I usually cover a little CFFI when I teach bindings.
Current CFFI release manager here- there's no set release schedule; basically just "whenever Armin asks" or when we notice low-priority fixes have been merged and sitting for a bit. Obviously if there's a critical bugfix or something, that'd drive more urgency in the release than a doc/testing update. The build and test process is largely automated, but still split across two CI providers, since Travis is still effectively the only one providing native workers for ARM/PPC/S390x (and emulated testing for those platforms is prohibitively slow). Neither of the CI providers can easily work directly with heptapod, and we're probably going to add M1 Mac wheels soon that will require a manual test run for the wheels on local hardware (due to lack of build workers and MacOS virtualization for M1) so there are some extra hoops to jump through that are somewhat unique to this project that prevent it from being a fully automatic affair.