...
For each of these databases there is a part of the RM code which talks to it. The lsf and workflow parts have been untouched for 5 years and even that was a those updates were very minor change. They haven't seen any significant activity for 7 or 8 years. The lsf and workflow parts of the code only need to run where RM itself is running, currently rhel6. The rest must run on any platform where builds are supported (currently rhel6 and rhel7).
...
If we used Jenkins for all builds we could perhaps vastly simplify the workflow section of the code. If we also stopped using lsf maybe we could replace both the workflow and lsf code with something much more streamlined. For the rest, I don't see any clear path to something significantly simpler.
Active Builds
Packages being built currently by RM are summarized in this Current Build Infrastructure page. Future plans include a new container package, ScienceTools_User (ROOTless subset of ScienceTools) and possibly support for a modern Mac OS for ScienceTools and ScienceTools_User.
The RM Ecosystem
In addition to the core functions described above, there are several others which depend to some degree on RM being constituted more or less as it currently is. For the most part this boils down to a dependence on one or both of the rd_releaseMgr database and tagging conventions.
...
Information displayed comes from RM database. It includes status of all builds, compile output, test output, red-dot display (comparison of most recent release build, release candidate build, and LATEST build).
Installers
Information needed to satisfy clients comes from RM database. Build products transported to client are created by RM.
...
The only tags RM creates are for LATEST builds (use most recent tag for each subpackage), but RM expects both package tags and container-wide tags to be of a certain form. We currently have a tool (C++ program) to help users create subpackage tags of the proper form and another (Python script) one for creating container-wide tags for releases and release candidates. We'll need something for the equivalent tasks which talk to git rather than CVS. (Assuming we don't change the required tag form these tools have nothing directly to do with the fate of RM; it's the need for new tools is driven by the move to git.)
...