Client remove

[jacomago]

Moved to https://github.com/ChannelFinder/reccaster

Requires ChannelFinder/reccaster#1 to be merged

[tynanford]

What about putting reccaster in https://github.com/epics-modules instead?

[simon-ess]

@tynanford raises a good question. I don't mind it being in the ChannelFinder organisation, but with the separation it ends up being a bit idiosyncratic...

[ralphlange]

There are arguments for both and examples for both.

If you were to search for
"The IOC side module of the reccaster/recceiver component of ChannelFinder"
Where would you look for it?

[jacomago]

There are arguments for both and examples for both.

If you were to search for "The IOC side module of the reccaster/recceiver component of ChannelFinder" Where would you look for it?

We could do a mirror in one direction or the other?

[ralphlange]

Like an automatically sync'ed fork?
That would work.

A soft link would be enough, but I don't think there are such simple solutions.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[anderslindho]

I would personally support putting this under epics-modules (why don't we just have a singular epics org?!?). I think your theoretical question can be mitigated with just documentation @ralphlange:

• in README of recCaster: "client for recsync protocol, to communicate with servers like recCeiver or recCeiver-java" (or whatever @shroffk decides to name his application)
• in README of recCeiver: "optional synchronisation node (server) for ChannelFinder which communicates via the recsync protocol. Example clients are recCaster (EPICS module) and recCaster-rs."
• in README of ChannelFinder: "can optionally be extended with recCeiver, recCeiver-java, etc." (since CF itself just is a CRUD app with some plugins for outwards HTTP)

[anderslindho]

IMO this MR depends on also a rename - I don't think this project should be called recsync if we now separate recCaster from recCeiver. I'd suggest calling this project just recCeiver and then creating a separate project called recsync-protocol (or similar) to capture the wire spec.

[ralphlange]

(why don't we just have a singular epics org?!?).

Base, Modules, Extensions was the original split since always.

Base: The Core stuff, under the responsibility of the Core Developers
Modules: Contributed software running on the IOC
Extensions: Contributed software outside the IOC

So the scope, people involved, teams, access, openness are pretty different.
If GitHub would allow repo folders or groups under orgs, it would be one org with three folders/groups.

[jacomago]

IMO this MR depends on also a rename - I don't think this project should be called recsync if we now separate recCaster from recCeiver. I'd suggest calling this project just recCeiver and then creating a separate project called recsync-protocol (or similar) to capture the wire spec.

I was thinking more removing recceiver from here and keeping this repo as the recsync protocol.

[jacomago]

IMO this MR depends on also a rename - I don't think this project should be called recsync if we now separate recCaster from recCeiver. I'd suggest calling this project just recCeiver and then creating a separate project called recsync-protocol (or similar) to capture the wire spec.

I was thinking more removing recceiver from here and keeping this repo as the recsync protocol.

i.e. pull out server to recceiver-twisted.

[jacomago]

@anderslindho I could pull out server first? I kind of wanted to rush this so we can block any PRs on client. Then do other changes after.

[shroffk]

reccaster location

Can we keep it under ChannelFinder and have an automatically sync'd mirror/fork under epics-modules

recsync repo backward compatiblity

Create a temporary git submodule client which points to ChannelFinder/reccaster. This is to support various build pipelines until every facility has a chance to port over.

In the long term we can move this repo to being just the protocol description

[shroffk]

ChannelFinder/reccaster#2

This works quite nicely... so we can easily setup and automatically updated fork un epics-modules

[jacomago]

Create a temporary git submodule client which points to ChannelFinder/reccaster. This is to support various build pipelines until every facility has a chance to port over.

I don't like this. Its already broken because submodules aren't automatically pulled. Better to make a hard line.

[simon-ess]

I agree with @jacomago. If we're moving this out, let's move it out.

I also don't like a mirror tbh; I'm fine with it being under the ChannelFinder org since other things are, but a mirror feels weird to me.

[anderslindho]

If GitHub would allow repo folders or groups under orgs, it would be one org with three folders/groups.

I am thinking that GH has pretty good support for this already by forming teams, but you mean this is annoying to work with @ralphlange?

[anderslindho]

i.e. pull out server to recceiver-twisted.

I don't like this name @jacomago. I otherwise agree with splitting it out, but IMO this product has claim on the name recceiver, without suffix.

[ralphlange]

If GitHub would allow repo folders or groups under orgs, it would be one org with three folders/groups.

I am thinking that GH has pretty good support for this already by forming teams, but you mean this is annoying to work with @ralphlange?

It did not when we moved EPICS Base to GitHub.

EPICS-Modules has 67 repos, EPICS-Extensions has 35 repos, EPICS-Base has 25 repos.
I do think it is annoying to work with a flat list of 127 repositories, without any grouping, except by renaming them all.
While you're at it, you could also consider adding epics-docs (5 repos) and epics-rip (25 repos), epics-motor (41 repos) and areadetector (70 repos) for a total of 268 repositories.

But I don't want to keep you from suggesting this at one of the meetings. Be prepared to be asked for a few important advantages...

[anderslindho]

I'd use teams and topics. A naming convention might be nice but shouldn't be necessary. I think the value gained lies both in discoverability (I have never heard of epics-rip!) but even more-so in simplifying configuration (CI, secrets, actions). Plus maybe even semantics - as you say this would/should have been a singular org if there had been access to better tools and features, which nowadays do exist. But I concede I am going to much off topic now here in this thread. I'll bring this as my next controversial topic if I come to more meetings. ;)

[jacomago]

So I see many topics discussed here, but the main question for this pull request appears to be, accept this version or do a submodule approach.

As mentioned I don't like the submodule approach:

• Most people don't add the 'add fetch submodules' in their pipelines so it probably won't fix them.
• Forcing the move with a hard cut I think is beneficial.

I do think we should be speedy with merging this pull request though. We don't want new MRs to come to this project on the reccaster module (I know that's rare at the moment).

[ralphlange]

This client-removal PR looks fine.

Otherwise, I am

• against doing a temporary submodule thing.
  Either do a topical parent (e.g. for the complete stack) that uses submodules to fix the module versions in a common release or let things break and apologize.
• against a sync'ed fork in epics-modules.
  a) the client was never there.
  b) it would be the first module appearing in multiple epics-related orgs. I would like to see a stronger justification for introducing a new possibly maintenance-effort-producing custom.

[tynanford]

I don't have a strong opinion on where this lives or whether to have a synced fork. So sticking with https://github.com/ChannelFinder/reccaster sounds good to me.

I think we should announce this removal on tech-talk first just to give everyone a heads up. It will break people's build scripts and CI

[shroffk]

I agree that we should announce a time line. How about we say we will merge this on 25th.
I was planning on getting everyone's green light during the upcoming meeting.

[ralphlange]

How/why would it break CI?

[tynanford]

I meant peoples local CI runners/scripts which might do git clone and then cd client && make

[ralphlange]

Ah.

What about replacing the client with a Makefile that prints an apology and the new URL?

[shroffk]

There is also all the packing projects ( like recsync-env ) which might have to be redone to keep them working.

Based on the theme of this discussion it seems like the print out message would be more an condescending comment rather than an apology :)

Anyway,
We should announce a date on techtalk/matrix - I vote for the 25th June, 2026.

[ralphlange]

If I were concerned, I would complain about less than two weeks notice, which seems short for a planned intervention.

But I'm not, so I won't.