Task #2770

Updated by Mark Abraham over 1 year ago

Several issues have been found in the shell code, and some test cases that use it. Neither Paul nor I know how to make a merge commit from release-2018 into release-2019. These are always complicated (because there are usually multiple changes and code has sometimes been refactored), and there has to be changes to regression tests also it can take large amounts of human and Jenkins time.

Erik and I think we need a change of policy regarding fixing on old branches. If someone thinks an issue is serious enough to fix on an old branch, then we need the onus to be on them and those who agree with them to make the fix and arrange for it to be done in multiple branches. The easiest way to implement that is if we by default do all fixes in the most recent release branch. If someone wants to backport a suitably serious fix, then they can do that, and it will be clear up front whether code refactoring is going to be a problem for doing that fix. Because the recent release branch has all the fixes, *nothing nothing needs to be merged*. merged. The semantics of all release branches are clear - they have the latest believed good version of the code.

In the short term, I think we need to revert the release-2018 shell fix until someone understands how to do a good job of it that will also work in release-2019 branch. I don't have time to look into it until at least January.

That the shell and normal-mode code is hard to understand and refactor is a separate problem. If it needs to be tightly coupled to force calculation then we need someone to step up and invest the time into decoupling it. For example, rerun, minimize and tpi have all been implemented in their own integrator loop, and shells could do likewise. Now there is not an additional layer of functions wrapping do_force to understand and maintain.