GitLab initiative – Short summary

Hello all,

Georges told me some people outside of our community asked about our GitLab initiative and that there is some confusion what the status is and that contrary to my belief, there is actual interest outside of GNOME. Since I guess people outside of our community didn’t follow our regular conversations, discussions and update reports in our GNOME mailing list for general desktop discussion,  I’ll do a short summarize.

Almost a year ago we started looking into alternatives to Bugzilla and cgit, and it became a long research, discussion and meeting with several parties and a few of us, Alberto, Allan and me, which then expanded to more people in order to give a different point of vision, like Emmanuele, Daniel, etc. All the research, work and reasoning we did and our eventual decision for a recommendation is written in our wiki page.

The actual status is that we are running a pilot program. The pilot program is a way to test GitLab in real life usage with real products, collect feedback, promote the usage and getting used to the tool by the GNOME community, and eventually to take a decision whether we migrate to GitLab the GNOME project as a whole.

Given the (social more than technical) complexity of moving all GNOME at once to a platform nobody of us used for GNOME projects, we decided to gradually move some willing maintainers and projects first, limiting the amount and the type of projects we migrate. In this pilot program, maintainers commit on a permanent migration to GitLab for the time being, to be aware of the issues we are dealing with, and to provide feedback when possible. When our tasks are done, technical issues fixed, current maintainers in the pilot program give a general positive feedback, community gets used a little bit more to the tool, and the upstream fixes we asked for are done, we will take the decision to move or not to GitLab GNOME as a whole.


Are there deadlines?

No. And at the same time, ASAP, which for a project of our magnitude is in the range of months.

What are you blocking on?

In tasks on our side, and in upstream issues. And of course, in our energy and time.

Can I help?

Yes, feel free to ping me for those task on our side.

Where is this hosted? Which projects moved?

You can take a look on our GitLab deployment.

Who is the person of contact/Who is taking most of the decisions?

Nowadays mostly me, with our sysadmin Andrea on the sysadmin side. I’m trying to represent as much as possible GNOME as a whole, and I’m focusing on trying to evaluate how much the community is happy with it or what has more or less priority. Obviously, this is the hardest part.

When will a decision be made? What are the requirements for that decision to happen?

This is more a social problem than technical. It needs to settle down on our community and is difficult to quantify. So no deadlines, and no hard requirements. As mentioned before, I’m trying to evaluate the consensus of the community and the overall status, and I’ll communicate to the GNOME community when I think a decision can be made and what I believe we should do, and get feedback at that point.

What’s the worst case scenario? How likely is that to happen?

The worst case scenario is that we decide we don’t move to GitLab as a whole, and then I expect the projects that migrated to GitLab to be migrated again to Bugzilla and cgit. There are other possible scenarios, but I don’t consider them for now. At this point this  scenario is unlikely to happen, since the initiative is going better than expected and I receive more queries to move projects that I can manage or that I consider we should migrate for now, the feedback in overall is positive and there is excitement in core maintainers and products to move to GitLab.

It’s true we have some blockers upstream that we are tracking in our instance as mentioned before and that they need a solution to move forward, but I’m confident with our meetings and discussion with GitLab eventually they will be fixed.

I have feedback/other questions/issues

General feedback can go to our wiki page or for public discussion. You can also contact me on IRC as csoriano in #gnome-hackers at or send me an email to for direct contact. Issues can be reported in our GitLab itself.


7 thoughts on “GitLab initiative – Short summary

  1. I’m curious as to why Pagure was “rejected early on in this evaluation, due to their contributor levels and sustainability”, given that it’s now basically an undroppable part of Fedora infrastructure, which means it implicitly has RH’s resources behind it…

    1. Hey Adam,

      Although I support the efforts of Pagure, it’s missing quite a few things in comparison to the big players like Phabricator, GitLab or GitHub that are necessary for projects like the ones we have at GNOME. Issue management (milestones, releases handling, organization wide management, kanban board, etc.), contribution workflow (UI for everything, conflicts resolution, strong review capabilities, resolvable discussions, etc.), strong CI, integration with bots, CLI tools, extensive and good admin interface, spam countermeasures (ReCaptcha, Akismet), pages support (like the websites), wikis, snippets… you name it.

      I personally made a test with Pagure, and unfortunately it was quite unreliable, finding few issues with it in the first minutes (maybe I was unlucky). I don’t know how many resources Red Hat is putting on it, but the current status was not enough for us and the team doing the evaluations agreed on this with not much doubt.

  2. You’re currently using cgit and bugzilla and you’re doing a test to determine whether GitLab is better……? You guys must be smoking some good s.h.i.t.

    Bugzilla is the worst bug tracker on the face of the earth. Every possible way in which one could possibly discourage contribution — Bugzilla has it. And cgit is a pile of spaghetti code. Why don’t just just stop your silly tests and switch already??

    What’s next? Are you going to have a committee meaning on whether drinking water would be better than drinking bleach?

    1. Seems you are missing the understanding of how a team of more than 500 people work and what the needs of those people working together for years in the same tool are.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: