In D41#1074, @johndan wrote:

General question, @tlatham : should I cherry-pick commits to bring this differential in line with the master (e.g. c38fa2a34f4a772754d1e8f610def10747d95104 - LauFormulaPar fix)?

Thanks for these improvements. They look fine to me.

Thanks very much for this @johndan. It looks good.
I think it would just be good to take the opportunity while we're at it to allow any of the parameters to float.
We should also include the name of the propagator in the name of the parameters so that if we have more than one K-matrix in a given fit we don't get identically named parameters appearing - this will cause problems with the sim-fit for example.
See the inline comments for details.

Many thanks @kreps, looks good to me.

• Update release notes

OK, good to go now, I'll take care of landing it later on.

• Reference Maniphest task in release notes

Hi Dan,

Hi @jback, many thanks for the changes and apologies for the delay in responding to them.
I think this looks good to go now.
Unless @kreps has any comments I think you can go ahead and "land" it onto master.

Hi @jback, sorry it's taken me so long to review this.
You can find here some technical points.
I'll try to compare the physics against the referenced paper next week, although I guess this was checked during the LHCb review?
You mention also testing it using testDecayModel but I can't find the json file(s) for this model. Could you include them in the next revision?

I suppose at least 'worker' should imply someone being paid for their services.

I think the first 3 you list don't really work very well in this context (as you say). However, 'coordinator/worker' describes rather well the relationship of the objects here.
A few alternatives to replace 'master' along the same lines could be 'manager', 'director', or 'controller'.
But I'm struggling to come up with other good alternatives to 'worker', which could maybe still be taken to be a bit pejorative? Maybe 'runner'? Any other ideas?

OK great, yes confirm the changes in rLAURA696d6d44a70e fix these concerns.

The CI build in the gitlab mirror of EvtGen is now working.
I've also committed the necessary changes to switch to using jsoncpp from LCG.
The build and test run successfully and you can see the details of the CI pipeline here:
https://gitlab.cern.ch/evtgen/evtgen/-/pipelines/1883808
I'm running everything in LCG_98 now because that includes the new versions of Photos and Tauola that include HepMC3 (btw it also includes EvtGen 2.0.0). There are now 4 builds:

• gcc9-opt
• gcc9-dbg
• gcc10-opt
• clang10-opt

and a test that uses the gcc9-dbg build. At present the test just runs your testDecayModel on one of the example json files you provided.
One thing I've noted is that the lack of a reference file does not result in the test exiting with a failure code, so that's something we need to look at.
The next step will be to analyse the contents of the push to see what files have changed and based on that work out what tests need to be run, etc.