When Microsoft bought github and we moved to our own gitlab instance, it became much harder for people to contribute code to our projects. The biggest issue was that people couldn’t fork the repos anymore freely. You could still send merge requests from cli, but the process was not well known.
I like that idea but I really think that the amount of junk posted on gitlab will rise when users don’t have to create a new account to contribute there.
Is the reason for self hosting gitlab instead of using gitlab.com due to costs?
Bidirectional mirroring sounds like it would complicate things more than it would help requiring someone to manage the exceptions on a regular basis. Not being that familiar with self hosted gitlab instances I’m assuming the ability to fork projects “freely” is more of a permissions issue than an actual product capability correct?
As for setting up discourse as an sso provider, really if someone wants to contribute creating an account on the manjaro gitlab isn’t that big of a deal vs creating a discourse account. Either way if the person doesn’t have an account they need to create one. I don’t know how opposed people are to creating an account to get something done but personally creating a gitlab.manjaro account isn’t that big of a deal (takes a couple of minutes at most).
Hopefully this whole forum experience has someone that now has the responsibility to actually regularly restore backups to an alternate location and TEST that they actually work. Is the same being done for the self hosted gitlab repository?
If not - the “only loss” would be the GitLab issues and configuration. Cloned Git repositories are already a backup of code and commit history - so this won’t be lost in such an event.
Yes, it is a permissions thing. The reason for those permissions is two fold:
since it is hosted by us, we are responsible for the content
licensing and pricing scales with the number users and repos.
So, if the permissions are too open, it can get quickly beyond our resources to maintain.
In the end, the mirroring might cause more issues than it solves, since we would have to essentially operate the same repos in two different locations.
It can be only one mirror to github or gitlab. Then we close the issues section on our instance. So people can send merge request and fork the repos. Also, they can send to us pull request.
Then again, if we handle the issue tracking on the mirror and merge the pull requests there, what is the point of having the private gitlab instance… All the code is public anyway.
Didn`t realize, but yeah you can’t fork any repo. But you can ask to have access? protect important branches and let other create specific branches? For examples protect master and only allow maintainer to merge into?
Yes, that is how it has worked now. You apply for developer access, and then you can make a branch and merge requests to master from there. However, it’s suboptimal, because
It is more hassle than usual
The licensing is based on the number of users. So when more people are granted access, we need to apply for more licenses.
So, I wish we can find a solution that could help with both of these.
The only way i see to avoid a lot of licenses is creating patches and post it as a ticket [irony] …or even E-Mail! Yeah let us get back to the old school way of contributing![/irony]
After searching a bit i am facing that gitlab don’t support merge requests between instances, but only within an instance. Maybe i am wrong?
Yes. That is why I am exploring two way mirroring: then people could fork the repos in gitlab.com and do the merge requests there. However, fragmentation is a problem.
I think I saw some documentation about creating merge requests from command line. If that works, we could maybe document the process and make a tutorial? But it needs some testing.
Opening more venues for contributing and maintaining package builds seems like a good idea to me. The idea should be explored further, and I think it would merit to have it’s own discussion. Can you open another topic about this?
Personally I would move everything to gihub but Phill is in favour of protecting users privacy, if you want to discuss this there is a link bellow, also things take time because they need to be revised and the publisher is responsible for the code they ship even if is made by someone else…
All the code is public anyway.
[irony] …or even E-Mail! Yeah let us get back to the old school way of contributing![/irony]