Lowering the threshold of contributing

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.

So, one solution might be to mirror out gitlab to either gitlab.com or github.com. This way users could freely fork our repos in gitlab/github and send merge requests to us. We would probably need bidirectional mirroring (Repository mirroring | GitLab), with only protected branches mirrored. However, this might lead to some fragmentation in issue tracking, when people would open issues both in github and gitlab.

Another option might be to explore local forking more thoroughly and make tutorial on how to use it?

One other thing we could do is to setup discourse as sso provider for gitlab, so people could open issues with their discourse credentials.

Any thoughts on this?

2 Likes

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.

That is also true. And we don’t have moderators on gitlab to keep the discussion in check.

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?

2 Likes

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… :thinking: All the code is public anyway.

I have some experiences on that… and yes, i agree that fragmentation is a big deal what would make the work even harder to maintain.

On my view, as nearly new manjaro user, login with a github or gitlab account shouldn’t be a problem. At least not for me.

Auswahl_217

But a big question rises: Why is it not possible to register on https://gitlab.manjaro.org/ ?

1 Like

it’s possible, but you can only create issues, no clone/PR

You can send a merge request in theory, but it is difficult when you can’t fork.

1 Like

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

  1. It is more hassle than usual
  2. 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 :smiley: [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.

What about moving to gitlab.com instead of self-hosting the repos?

1 Like

I think that has to be considered as well.

1 Like

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?

1 Like

What would be the cons of moving to gitlab.com? if other projects are there or in github, why can’t Manjaro also be there?

1 Like

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…