The split of recsync into separate repositories is partly done. reccaster now
lives at ChannelFinder/reccaster, and #103 was closed on that basis. The end
state discussed at the time was three projects: the protocol specification, the
EPICS module, and the server.
The server has not moved, and I do not think it can until we agree on one point.
The name recceiver in this organisation currently refers to the Java/Spring Boot
implementation, so the Python/Twisted server in ./server has no destination.
That leaves recsync holding a server it cannot be separated from, and two
projects sharing one name.
The effects are visible now. The recsync README describes RecCeiver as the
server in ./server while linking reccaster to its new repository. The reccaster
README points to recsync/server rather than to ChannelFinder/recceiver, because
that is where the server it has always been tested against is released from. A
user looking for recceiver source, a release, or somewhere to file a bug has two
plausible destinations and nothing telling them which one they want.
One constraint before the options. The Python server is in production at ESS and
at a number of other labs, and we are not in a position to stop running it until
we have a replacement of our own. It needs a maintained home under a name of its
own. Leaving it in recsync is not that: a specification repository that also
ships one implementation recreates the coupling that motivated the split.
Three end states, and I can work with any of them:
- The Java implementation keeps recceiver, and the Python server takes a
qualified name such as recceiver-python.
- The Java implementation takes a qualified name, for example
phoebus-recceiver to match its org.phoebus groupId, and the Python server
moves to recceiver.
- Both take qualified names, recceiver-java and recceiver-python, and the bare
name is left unused.
I would argue against the first, and the reason is worth stating in general
terms rather than as a preference. A language suffix describes an
implementation. An unqualified name describes the project. Qualifying one side
only therefore does more than disambiguate: it decides which implementation is
the project and which is a variant of it. If qualifiers are the right answer
here, they should apply to both, which is what the third option is for.
recsync-rs is already named this way. It also matters beyond these two, since
ESS expects to write a server in Rust or Go once the scope questions are
settled, most likely using recsync-rs for the wire format, and a convention of
first claim leaves nothing for anything that comes later.
Whichever name it ends up with, the Python server should move with its full
history, tags and releases, so that provenance sits in the repository rather
than in the name.
Renaming is cheaper now than later. ChannelFinder/recceiver has no tags and no
releases, and as far as I can see nothing is published from it yet, so a rename
there would break nothing today and GitHub would redirect existing clones. Once
it has releases and sites pin them, that stops being true. The Python server has
thirteen releases and the tags that current deployments were installed from.
The Java implementation's reported performance against the Python server is a
real improvement, and I am not arguing against that work or asking for anything
to be reversed. This is about which repository carries which project identity,
and about users being able to find what they are looking for.
I am happy to open the follow-up README and link PRs in recsync and reccaster
once this is settled. If there is no decision here within the next few weeks I
will raise it at the next collaboration meeting and on Tech-Talk so that it gets
resolved one way or the other.
@mdavidsaver @ralphlange @jwlodek @jacomago @tynanford @simon-ess @shroffk
The split of recsync into separate repositories is partly done. reccaster now
lives at ChannelFinder/reccaster, and #103 was closed on that basis. The end
state discussed at the time was three projects: the protocol specification, the
EPICS module, and the server.
The server has not moved, and I do not think it can until we agree on one point.
The name recceiver in this organisation currently refers to the Java/Spring Boot
implementation, so the Python/Twisted server in ./server has no destination.
That leaves recsync holding a server it cannot be separated from, and two
projects sharing one name.
The effects are visible now. The recsync README describes RecCeiver as the
server in ./server while linking reccaster to its new repository. The reccaster
README points to recsync/server rather than to ChannelFinder/recceiver, because
that is where the server it has always been tested against is released from. A
user looking for recceiver source, a release, or somewhere to file a bug has two
plausible destinations and nothing telling them which one they want.
One constraint before the options. The Python server is in production at ESS and
at a number of other labs, and we are not in a position to stop running it until
we have a replacement of our own. It needs a maintained home under a name of its
own. Leaving it in recsync is not that: a specification repository that also
ships one implementation recreates the coupling that motivated the split.
Three end states, and I can work with any of them:
qualified name such as recceiver-python.
phoebus-recceiver to match its org.phoebus groupId, and the Python server
moves to recceiver.
name is left unused.
I would argue against the first, and the reason is worth stating in general
terms rather than as a preference. A language suffix describes an
implementation. An unqualified name describes the project. Qualifying one side
only therefore does more than disambiguate: it decides which implementation is
the project and which is a variant of it. If qualifiers are the right answer
here, they should apply to both, which is what the third option is for.
recsync-rs is already named this way. It also matters beyond these two, since
ESS expects to write a server in Rust or Go once the scope questions are
settled, most likely using recsync-rs for the wire format, and a convention of
first claim leaves nothing for anything that comes later.
Whichever name it ends up with, the Python server should move with its full
history, tags and releases, so that provenance sits in the repository rather
than in the name.
Renaming is cheaper now than later. ChannelFinder/recceiver has no tags and no
releases, and as far as I can see nothing is published from it yet, so a rename
there would break nothing today and GitHub would redirect existing clones. Once
it has releases and sites pin them, that stops being true. The Python server has
thirteen releases and the tags that current deployments were installed from.
The Java implementation's reported performance against the Python server is a
real improvement, and I am not arguing against that work or asking for anything
to be reversed. This is about which repository carries which project identity,
and about users being able to find what they are looking for.
I am happy to open the follow-up README and link PRs in recsync and reccaster
once this is settled. If there is no decision here within the next few weeks I
will raise it at the next collaboration meeting and on Tech-Talk so that it gets
resolved one way or the other.
@mdavidsaver @ralphlange @jwlodek @jacomago @tynanford @simon-ess @shroffk