Thank you.
It was not readily apparent that Safe Network / sn_api · GitLab is the https://github.com/maidsafe/sn_api counterpart as the names differ. Although I find the sn_api repo name confusing, I think any mirror should contain exactly the same repo names, as well as all other data.
If MaidSafe eventually moves the source into a foundation, those URLs would be excellent to use. When Safe’s self-hosting and dev takes place there, oldnet mirrors of the project will remain important for gradually on-boarding new devs.
Inexplicably so, unfortunately. It also would probably be best to begin with a uni-directional flow from GitHub to GitLab. Nevertheless, code is a helpful start as I was able to fork https://gitlab.com/l4tch/safe-api.
Synthesized from your and @joshuef’s suggestions, I propose we evaluate the following workflow:
- @frabrunelle ensures Safe Network · GitLab mirrors MaidSafe · GitHub.
- I develop SAFE CLI subcommand suggestions: reset and uninstall on a dedicated branch (
gitlab-reset) of my https://gitlab.com/l4tch/safe-api fork. - I open a merge (pull) request on my fork when
safe resetis ready for review and discussion takes place in SAFE CLI subcommand suggestions: reset and uninstall, not the merge request, so any content generated in the course of developing Safe remains in Safe’s data silos. - When the merge request is in an acceptable state, I generate a patch and attach it as a comment in SAFE CLI subcommand suggestions: reset and uninstall.