[ET Trac] [Einstein Toolkit] #1365: Kranc-generated thorns should be regenerated before the release

[Einstein Toolkit]

#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)

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1365#comment:7>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit