#1365: Kranc-generated thorns should be regenerated before the release ---------------------+------------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: Other | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by hinder):
Replying to [comment:4 eschnett]:
I don't see a reason to change the released version. It has been tested,
it works, so let's keep it that way.
The reason is that it can cause surprise to users who might want to make modifications to the code. They will regenerate the thorn and see some unrelated changes. If the changes are minor (formatting etc), I think they should be included in the point release. If not, then we should just chalk it up to experience and try to do better next time. We should also warn people that these thorns might change if regenerated.
Replying to [comment:6 knarf]:
In the light of this for the future: what would be a good way to do this
automatically? Is there a good way? Doing this automatically would require a machine with valid license, plus commit credentials on disk. In addition, it should probably run the testsuites and only commit if they pass (or something alike). Of course, we could just continue as we did (but maybe a bit more careful around release-time) - by hand.
The process should be that whenever changes are made to Kranc, an ET developer (probably the one who made the changes) should verify that the changes to the generated code look reasonable, and commit them. In case we forget, we should have an automated system which reminds us. We have the build VM at UCD which has access to a Mathematica licence server, and it has been on my to-do list for a while to arrange such a process. It should be straightforward. My plan would be to have the Kranc-generated thorns regenerated on the build server after relevant commits in a separate "build job", and any differences would be classed as "test failures" for that job, and would be reported to the usual channels. It would then be up to a developer to verify the changes and regenerate the thorn. I don't think they should be committed automatically. This would require the build server (which lives behind a web application) to have commit access to our code repositories, and it might be tricky to handle the case of conflicts. It would also require, as you say, that the build server run the tests on the newly-generated code, and have even more intelligence about what to do then. I think it is much simpler and safer to require manual intervention in this case.
Next time, the release process as listed at https://docs.einsteintoolkit.org/et-docs/Release_Process should be followed. This includes
Ensure that any manually-generated files are consistent (i.e. regenerate
McLachlan, WeylScal4 and EinsteinExact from their source with the current version of Kranc)