> And we do want to make sure that all the features you really need are there.
So far, everything is great, but we would love to have:
- Custom Fields, in order to leave trac (such a pain, this service is);
- A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice;
- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).
(Btw, we currently use jenkins and we will move to gitlab-ci.)
> - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice;
We actually have an issue open about it - https://gitlab.com/gitlab-org/gitlab-ce/issues/4013. As the issue label suggests, it's definitely a moonshot, but completely achievable in small steps / iterations.
> - Custom Fields, in order to leave trac (such a pain, this service is);
> - Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).
Could you rephrase this? I think I'm missing the point. You can update a MR with a regular push. You can also browse through different versions of a MR diff (https://docs.gitlab.com/ee/user/project/merge_requests/versi...). A force push "is required" only if your local history doesn't match the remote history.
I think ActivityPub would be a good fit for federation across GitLab instances and would have a real chance to displace Github for open-source projects, if implemented right.
Hell, git-ssb is already working! ActivityPub would be great for GNU Social or Mastodon (or, of course, Pleroma), but I still have a soft spot for Scuttlebutt.
>- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).
Although not identical, it's worth noting that GitLab tracks all versions of MRs throughout the life of an MR. So, if you force push, you can compare the MR before and after the force push, via the "Changes" tab. I could be wrong, but I believe this is actually a leg up on what GitHub provides.
And we do want to make sure that all the features you really need are there. I understand the VideoLan needs https://gitlab.com/gitlab-org/gitlab-ce/issues/40321 and we're prioritizing it.