Branches divergencies

[lpetre-ulb]

Brief summary of issue

During the branches clean-up, I noticed that several more or less active branches have diverged. Compared to release/legacy-1.0 (previously generic-amc-RPC-v3-short-term), generic-amc-release-v3-RPC-playground and master have diverged.

• generic-amc-release-v3-RPC-playground seems to have been an attempt to integrate the RPC modules into the Python. If this is truly the case, most of the features are probably integrated into release/legacy-1.0.
• master has only diverged from release/legacy-1.0 by two commits. They introduce the merge with the old generic-amc-release-v3 and the 1.1.0 release. Why is the release 1.1.0 older than the 1.0 release from the legacy branch, while not being the base of develop? Anyway, everything those two commits seem to be included into develop.

Since those two branches are not expected to be maintained and haven't seen new commits in a year, one may want to simply delete them without further consideration. I would however prefer to first check that nothing is going to be lost. Said otherwise, that no bug fix or feature is lost.

Does any developer knows if it is safe from the bug fix or feature point of view to delete generic-amc-release-v3-RPC-playground and master?

[mexanick]

release/legacy-1.0 vs generic-amc-release-v3-RPC-playground:
the latter is obsolete and can be deleted. It was a short-term introduction of xhal functionality which has been later merged, reshuffled and sort of polished.
release/legacy-1.0 vs master:
The differences seems to be quite simple and straightforward. They consist of three kinds:

1. Changes in build, tag and release system. @jsturdy needs to comment on this divergence, we need to select one way or another and merge into a single branch.
2. All logging macros changed definition from <LOG_LEVEL> to <CMSGEMOS_LOG_LEVEL>. This is just a matter of choice. I don't think we need it.
3. Two packages are completely missing from the legacy release:

• gemdaqmonitor: this package is working, but not used. I have mixed feelings about whether we are willing to keep it... On one hand, we can keep the working thing in the project, on the other it will become outdated soon, we are not planning development here and it is not really used... So I'd tend to keep things simple and remove it from legacy, but if anyone wants to keep it - raise your hand now.
• gemonlinedb - this functionality is under active development and won't be ever used in legacy release (actually can't be). I would not add it.

So IMHO, we only need to clarify the build system and merge it if required, the rest of the things aren't needed in the legacy

[jsturdy]

The only branch I expect to be (semi)-active in this repository moving forward is the legacy release branch, and it is currently self contained.
Given that all active development of this package has already moved, I don't understand the point of this issue.
If, for whatever reason, someone wants to take the drastic step of deleting all unused branches in a public (semi)-archived repository when the development has moved elsewhere, that is a choice that someone could make...