Improving SAFE's contribution accessibility

If was used to mirror the repos on GitHub those of us who prefer to not use GitHub would still be able to directly contribute to SAFE.

Ultimately SAFE should self-host its repos however until then a larger door for helpers may add value.

1 Like

Would pull requests and comments created in Gitlab automatically pull over in to GitHub if it was mirrored?

I wouldn’t want a situation where the team had to do a lot of clerical work to keep the different repository stores in sync. Given they currently use GitHub for project management it’s unlikely they’ll transition away, but if having Gitlab work in tandem was effortless I can’t see any reason not to.


From brief web searching that appears to be possible although I’m not certain.

I agree that any non-productive overhead is not desirable. Configuring the GitLab repos and would require several hours. Repo mirroring from GitHub would then be automated. The only overhead I foresee is actually using GitLab, if there are no tools to automatically sync back to GitHub.

For example if I open an issue or a pull request on a GitLab repo, someone(s) would receive notifications and handle it as appropriate. That’s not ideal as having the issue or pull request in a single location is, however I would argue that it’s better than not receiving the contribution.

1 Like

Hi @latch we were actually looking into doing exactly this at the turn of the year when things had quietened down.

The only person with access to is a former employee and so we reached out to see if he could transfer access over. Unfortunately the password he thought he had set for this didn’t work and the password reset function was not sending to his old MaidSafe email address (we revived it and set it to forward to me if anything came through) or his personal address (he said he would let us know if anything came through). We ended up parking the idea in the meantime as some other things took priority again.

If I remember correctly we would have to upgrade the GitLab account to a paid account for mirroring. There was a couple of potential workarounds I found online but it wouldn’t have included comments, etc, so official mirroring would have been the best way forward.

My main motivation for mirroring to GitLab was for resilience - what if GitHub decided to take us offline at some point? I/We will look back at this again at some point when there’s a bit of spare time, it makes sense to do it for several reasons.


Another option could be to use (which I created a few years ago) :slightly_smiling_face:

I think it could make sense to move our repos to a community-managed organization eventually (I also have if we want to do it on GitHub). This is what many open source projects do (e.g.,,,

Official mirroring also wouldn’t include comments, etc.

continuous sync between two systems is a very hard problem. It is very difficult to prevent inconsistencies would likely be error prone.

Closing this issue since we don’t plan to support continuous bi-directional mirroring of repositories, issues or merge requests with GitHub.


Hmmmm, without comments (and issues?), that’s definitely not optimal. :frowning:

@latch We could look at accepting git patches perhaps? That should be easy enough to do and I guess could be uploaded to the forum (@frabrunelle not sure what’s possible/makes sense there) ? Or sent via email eg.


I just added most MaidSafe repos to with mirroring enabled.

Here’s what I suggest:

Contributors who prefer to not use GitHub can submit a merge request to the corresponding GitLab repo and then open a topic on this forum with a link to the merge request. Or perhaps we could have a single topic dedicated to GitLab merge requests and people would simply have to post a reply with a link to their GitLab merge request (as opposed to creating a new topic). I think this second option would work well if MaidSafe developers are OK with providing feedback on the merge request on GitLab. Once the merge request seems to be in good shape, someone could volunteer to submit an equivalent pull request on the corresponding GitHub repo on behalf of the person who submitted the GitLab merge request.

Let me know what you think :slightly_smiling_face:

1 Like

That sounds like an awful lot of extra manual work… That being said, I don’t see there being much use of Gitlab anyway in this instance so it probably won’t amount to much extra work in the long term.

There should definitely be 1 topic per pull request, it will reduce confusion when we have multiple PRS in action.

Hmmm, happy to try it out. Definitely sounds like more manual steps. But let’s give it a whilrl.

If it proves untenable I’d say we can fall back on just making patches and get them submitted/a pr created. If it’s going to be used a lot I’m sure we can automate the PR generation eg.