Gitlab for Haiku?

Development
1

Currently, Haiku repositories are both hosted on Haiku’s servers and on GitHub. OS (and user guide/documentation) development happen through the repositories on Haiku’s servers and Gerrit whilst bugs and tasks plus some documentation (i.e. for translations) are filed through Trac. Web infrastructure (the main Haiku website, the Haiku Inc. website plus Docker infrastructure) development happens through GitHub.

Whilst this status quo is how we’ve been handling development, it’s probably not the best way to go about it. Why? The development of Haiku-related projects, whether that be the OS or the web infrastructure, is split across two different platforms. Relatively new contributors might take a while to get used to (and perhaps learn how to use) Gerrit and Git, whilst some people are reluctant to use GitHub due to various privacy and other concerns. I should note that for some reason Gerrit requires a GitHub account, which is understandably a bit strange. Additionally, having multiple dev tools like Gerrit and Trac means things to maintain and keep up to date.

Is there a way to simplify the process? Well, possibly. After doing a bit of research, I found that GitLab, might be a good solution. GitLab is essentially the OSS version of GitHub - it’s fully open-source and provides the same, if not similar functionality to GitHub. Additionally, it claims it can replace tools like Trac and Gerrit, and provide additional functionality like code-integrity checking. Since it is open-source, we can also self-host a GitLab instance, or we can also choose to have our repositories hosted on GitLab’s servers and get full access to GitLab features as part of their open-source program.

If what GitLab claims is true, we can do away with Trac (there are many open-source migration tools available online), Gerrit, cgit and have one single place for development that is easy to use, even for newbies, thus cutting down on sys-admin resources whilst making development simpler. Additionally, there is the possibility that the development of Haiku will be further enhanced through features like code monitoring and security/integrity checks.

Whilst I’m not too sure whether GitLab is suitable for us or not, I hope someone who is more knowledgeable could perhaps look into its suitability for Haiku. (Also, thank you for reading this far :sweat_smile:)

1 Like
2

Hey, as one of the people who refuse to use github because of having to depend on MS and having to agree to their TOS, I am also opposed to using gitlab, the reasons here are similar in that there is more of a dependency on external services for haiku than before. In the case of self-hosting though I think gitlab is pretty much the worst option one could pick, their UI is pretty horrible and i highly doubt it would scale to our needs.

Having severall services good at one thing isn’t a disadvantage IMO. As soon as gerrit can be used with an LDAP account i will be happy there. (there are some improvements one can make to some services we self-host but nothing pressing enough to consider switching everything)

For CI and stuff, someone ‘just’ needs to build it, it’s not easy but I think it is doubtfull that a server optimized for running docket/linux will help us much there. (and i already rented a server for that, to build Haiku on FreeBSD and run the build in tests… just need to finish it :g)

Just my 2 cents.

1 Like
3

Wow - is it that bad? Are there any alternatives you would recommend?

4

I’m using Gitea but I don’t know right now if it covers all the things you need. It certainly is FS though and can be self-hosted on a server.

5

Well, i’m fine with the status quo. I’m more interested in getting some more integration between Gerrit and Concourse.

2 Likes
6

I don’t understand how the solution to “we are using two tools” can be “let’s add a third tool”.

Gitlab (and Github, for that matter) issue tracker is very insufficient for our needs. We have our Trac install with custom plugins and someone who is taking care of it (thanks nielx!). I’m fairly sure this part won’t go away.

As for Gerrit vs Github/Gitlab, the debate is going on for some time. Historically, we had no tool like this at all and people would simply attach their patches to Trac tickets. Personally I find the workflow of Gerrit better than the one used by Github/Gitlab (but not everyone agrees). They are certainly not identical, here is an attempt to sum it up in a not too technical way:

Github and Gitlab focus on a model where contributors have to create their own “fork” of a project, and make changes there. Then, they have to create a “pull request” asking the original repository to integrate their changes. The big downside of this model is that everyone is now dealing with at least 3 copies of the repository: the original, the fork, and their local working copy on their computer. My experience reviewing code from people unfamiliar with that workflow is that it is extremely confusing: people will forget to synchronize their fork, push changes in the wrong branch, and get away with it by deleting their fork and local copy and starting over all the time. The suggested solution by more experienced developers is to use branches. Branches are, in some way, an extra copy/version of the code in the same repository. I think it only makes things even more complicated.

On the other hand, Gerrit does not have a notion of a fork. There are only two versions of the repository (a local working copy, and our server). Synchronization between the two is easy (“git pull”) if you follow our instructions for setting it up.

The other main difference is that Github and Gitlab encourage to review work by the complete branch. By default they don’t even show a list of commits, and each review generates a “merge request” commit. The result of this is that the commit history tend to be not so clean, you can usually see people trying something in a commit, then changing it later in another one. Gerrit, on the other hand, doesn’t really have a notion of branches in the code review interface. Instead it focuses on individual commits. This forces people to make sure their git history is clean. This is important for Haiku, because we are otherwise not that good at developer documentation and often the commit history is the only explanation we have as to why things were done in a certain way.

I use Gitlab everyday at work and know it very well. There are some good sides to it, for example the way they integrate build pipelines for continuous integration is better than what Gerrit has in terms of ease of managing it. But, the bugtracker certainly can’t replace Trac (it could replace a basic install for simple needs, but not ours with all the plugins we use to manage several thousands bugreports). And it is a really different way of thinking about the code review process.

This is in fact one of the reasons we use both Github and Gerrit: Github is convenient for easy setup of some things (such as automated updates of the website) and requires almost no intervention from our admins (we are using Github infrastructure). But it is not matching with the way we are currently handling code review for Haiku itself. So, a change here would not be just about the tools, but more about the way we work.

8 Likes