...
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).
...
Information displayed comes from RM database. It includes status of all builds, compile output, test output, red-dot display (compares comparison of most recent release build, release candidate build, and LATEST build).
...
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.)
...