Please don't break workflows with changes in common_bench. We (the EIC project detector) are an active project on a tight schedule. That timeline includes tagged and benchmarked geometry, reconstruction and container releases on the first Monday of the month. It is frustrating to see workflow failures introduced a day before in service of the 2nd detector, and then be told to just fix it. Please revert the changes in common_bench, first file an issue giving us notice, and then make breaking changes only after this has been addressed. I can address this later in the week but not on a Sunday after stuff is already broken.
As an intermediate policy until we can get something else worked out, please don't make changes without review from someone in ePIC. It can be @cpeng, @veprbl, @sly2j, etc. If workflows are already breaking in week 1 of det2 efforts, then we're doing something wrong and it's going to lead to (more) frustration. Hyrum's law applies whether it's intentional or not...
One of the main things we've been trying to instill in developers in ePIC is that code needs to be reviewed and needs to pass all checks before it gets merged, including for changes from all of us in development leadership.
As far as I know, there are no other issues. I'll post issues for any problems I encounter (or, more likely, submit merge requests with fixes, if past experience is a guide).
Don't get me wrong: I do appreciate all the design that will make this able to support both ePIC and detector 2 (or even just support ePIC better). Nevertheless, there are ways in which we, inevitably and probably unknowingly, have started to depend on undocumented interfaces (or edge case behaviors of documented interfaces). It makes sense to make those instances explicit, of course, but in the meantime it is also easy to break things; even today it took some time for us to figure out why we suddenly were getting git clone errors. That's where the reviews/involvement will help with getting at least more of us in the loop on what may be happening.