Deploy new RScore repo structure

[TheoPannetier]

• [x] #6
• [x] #8 solve merge conflicts; make sure optional macros are marked as new changes in git history
• [x] #5
• [x] delete branches that aren't main, develop or macros, or active feature branches
• [x] Transfer repo ownership from @JetteReeg to RSdevs
• [x] Create public mirror

[JetteReeg]

Regarding point 4: the branches spatial_variance_demo and thread_safe include new features for the R package. I need to check whether thread_safe actually involves files in RScore. Spatial_variance_demo include new features which we wanted to discuss in the whole developer group. Not sure if we really should merge them into macros (and having additional macros?) or if we should keep them for now, but integrate the at some point in the near future?

[TheoPannetier]

I would keep them as "feature" branches, that is branches behind develop where new features are actively being developped :)

[TheoPannetier]

So no need to change anything with them - I just updated the description

[JetteReeg]

I guess I can now delete release-r, release-batch and release-common? And the CONTAIN branch should be merged to the macros branch?

[TheoPannetier]

For release- branches, yes! I'm unsure about CONTAIN - is it just a version of macros cleaned with just the RS_CONTAIN macro enabled? Let me open a quick PR to compare and inspect the differences.

[TheoPannetier]

So, AFAICS CONTAIN is a streamlined version of outdated code that is otherwise also available on macros. I reckon we should be able to delete it safely, but let me check with @GretaBocedi first. In the meantime, I would keep CONTAIN for now and proceed with the deployment.

[TheoPannetier]

GitHub doc on transferring repos: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository tl;dr seems safe to transfer, issues and PRs etc. are conserved as long as all contributors are member of the recipient organisation.

[GretaBocedi]

So, AFAICS CONTAIN is a streamlined version of outdated code that is otherwise also available on macros. I reckon we should be able to delete it safely, but let me check with @GretaBocedi first. In the meantime, I would keep CONTAIN for now and proceed with the deployment.

@TheoPannetier, I think the best would be to check that with Steve. Should I organise a meeting?

[TheoPannetier]

Sounds good, would be a good opportunity to meet Steve! Although I feel this could also be addressed by an email - are there any other topics you'd like to discuss with him?

[TheoPannetier]

Ok, let's keep CONTAIN live for now and proceed with the transfer of ownership 👍

[JetteReeg]

Great! I think it is best to have the repositories in the RangeShifter organization. I will create a new team there, so we can distinghuish between RS developers and other RS members. Only RS developers should then have access to the private RS repositories. In that way we can have all RS repositories in one organization. RSDevs can then be 'archived'.

For now, I will add Damaris, @GretaBocedi, @TheoPannetier to the developer team. Who else should be on the team? Probably Justin (who seem not to be a member of RangeShifter?), but also Steve and Roslyn?

[TheoPannetier]

Closing this, as every item has been ticked! We can keep the discussion going :)