Create and test a candidate release targeted for use at protoDUNE
[I'm creating this Issue a little late. Discussions about this topic have been going on for a couple of days now.]
On Monday (two days ago), we learned that Ron had a version of the artdaq code that started with the pdune_* branch (in artdaq, artdaq-core, and artdaq-utilities) and cherry-picked useful changes from the develop branch. This version showed improved behavior compared to the pdune_* branch. Eric gave a presentation on the differences between this version and the pdune_* branch.
This morning (Wednesday), Ron reported that there is a mis-behavior that is seen in his version of the code with the "mediumsystem_with_routingmaster" configuration that is not seen on the develop or pdune_* branches. After some discussion about the right approach, we decided to switch our attention to the develop branch and starting testing it, as the candidate to be released to protoDUNE.
Actually, Ron is going to create branches based on relatively recent versions of code on the develop branch and use that as the basis of our tests. These branches will not only insulate us from unrelated changes on the develop branch, it will allow us to control the versions of other products in the product_deps file so that they do not change from what is currently being used at protoDUNE.
Along with the planned tests on the mu2edaq cluster, we talked about some specific tests at protoDUNE that might give us insight to the reliability of any candidate release.