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. ;)