Infrastructure

Rather than replace Gerrit and Bugzilla, I would invest funds into improving them. They are powerful tools and any shortcomings in (presumably) the user interface are fixable.

I have said this many times: GitLab's (or -Hub's) Issues lack the sophistication of Bugzilla. GitLab Issues do not answer the needs of a serious QA team.

The delay of getting the revamped Bugzilla released has been very unfortunate, but it is now deployable (still unreleased): https://github.com/bugzilla/harmony

Gerrit has been receiving lots of user experience improvements in the past couple of years thanks to Google investing in that department. We should join and help rather than be passive consumers.

Wikimedia is currently evaluating GitLab to replace Gerrit:
https://www.mediawiki.org/wiki/GitLab_consultation
https://www.mediawiki.org/wiki/Talk:GitLab_consultation

Note comments such as

"we should be conscious about the trade-offs. If we switch

• productivity of some developers, like me, would likely decrease temporarily as we learn and adapt.
• productivity of some developers, like me, could possibly decrease permanently, if GitLab does not support certain kind of workflows as fluently."

GitLab has an open core model, which is always suspicious.

The LibreOffice infra team actually deployed GitLab to host devops stuff, but eventually decommissioned it and now all of their material is in Gerrit.

I don't think there are the "funds" available to invest needed to improve them substantially (they are probably in the range of what is needed to improve LibreOffice substantially and in that case I'd vote for improving LibreOffice substantially. Since LibreOffice has not been improved substantially in the past I conclude that most likely those funds are simply not available).

Also note that having issues and merge requests in one place has usability benefits.

Please name examples where GitLab's issue tracking is lacking stuff in comparison to Bugzilla. It is most surely answering the needs of a serious QA team, at least it is used by many serious QA teams (including GitLab's own).

That being said, it is good to hear that there is improvement for Bugzilla and Gerrit. I am really looking forward to the long awaited Bugzilla update, although it is still behind in terms of usability from my experience with it.

I skimmed through the Wikimedia discussion page and my takeaway was that the opinions were pretty mixed and there were also comments noting problems arising of sticking with Gerrit. Thus your quotes only reflect one side of the problem.

One has to evaluate whether those problems are worth the drawbacks. As for most changes you are right that it will be a tradeoff.

From what I see lack of manpower, no matter which system is used is currently the biggest problem for LibreOffice. So I could understand that due to lacking manpower one is not doing the transition.

Beluga Beluga wrote:

Claudius Ellsel wrote:

I don't think there are the "funds" available to invest needed to improve them substantially (they are probably in the range of what is needed to improve LibreOffice substantially and in that case I'd vote for improving LibreOffice substantially. Since LibreOffice has not been improved substantially in the past I conclude that most likely those funds are simply not available).

I don't think it is fair for you to make statements like these, when you clearly have nothing to base them on. I'm a web developer myself and I have recently experimented with the Gerrit UI and in my view, a single full-time JavaScript developer could basically make all our dreams come true for both Bugzilla and Gerrit.

I had something to base my assumptions on, so in the contrary I think it is not fair of you to say I had clearly nothing to base them on. Nonetheless, my assumptions might be wrong. I guess this full-time dev would need a substantial amount of time to make those dreams come true? Still, if you have the funds, is there already a process or discussion to hire such developer? That would be the logical consequence of your statement before that you prefer to invest funds into improving the currently used products instead of changing them (my assumption was that there are not sufficient funds to hire the required dev power).

Please name examples where GitLab's issue tracking is lacking stuff in comparison to Bugzilla. It is most surely answering the needs of a serious QA team, at least it is used by many serious QA teams (including GitLab's own).

We have already had this discussion last year: https://bugs.documentfoundation.org/show_bug.cgi?id=126818

Ah, yes. Thanks for linking the reference, I had completely forgotten about that discussion.

I think it's rather perplexing that you want me to write those arguments again.

I on the other hand think it's rather perplexing that you think you gave any arguments why GitLab is inferior for issue triaging there. Really, I skimmed through it again and all you wrote seems to be basically quotes of people stating they don't think GitLab can work for large projects (often without even given a proper reason) and I think that you don't like labels (I don't like dropdown boxes on the contrary :), so not really a point, I guess).

So to get this discussion back to facts a bit more, a short list of shortcomings of GitLab from your perspective will work wonders. I'll start with the label based workflow that is extremely flexible on the one hand, but arguably might be harder to use or to reflect all needed tracking options.

From what I see lack of manpower, no matter which system is used is currently the biggest problem for LibreOffice. So I could understand that due to lacking manpower one is not doing the transition.

We do drop solutions that are falling behind. Case in point: https://redmine.documentfoundation.org/issues/2952

Thanks for the example. I guess it just comes down to what one expect of a solution, how hard a transition is and where to draw a line of "falling behind". Sorry if I was wrong with the lacking manpower. It is what currently seems to be slowing down KDE from completing their GitLab transition, but their situation might be different.

It just makes sense to avoid pointless churn, if we can instead improve a working system.

Fully agree. However I doubt that it is worth the effort, but I can also see your standpoint. It definitely also would be an ongoing effort with GitLab having the needed features implemented by them or asking them to make them available in the open source version.

Claudius Ellsel wrote:

I on the other hand think it's rather perplexing that you think you gave any arguments why GitLab is inferior for issue triaging there. Really, I skimmed through it again and all you wrote seems to be basically quotes of people stating they don't think GitLab can work for large projects (often without even given a proper reason) and I think that you don't like labels (I don't like dropdown boxes on the contrary :), so not really a point, I guess).

So to get this discussion back to facts a bit more, a short list of shortcomings of GitLab from your perspective will work wonders. I'll start with the label based workflow that is extremely flexible on the one hand, but arguably might be harder to use or to reflect all needed tracking options.

I quoted other people, because otherwise it would have been just my word against your hypothesis and I also did not want to spend energy on rewriting everything that has been said. I'm not sure saying GitLab Issues has shortcomings is the right way to put it. It just has a different goal and is not as powerful and flexible as a dedicated bug tracking system.

I don't understand your comment on not liking dropdown boxes - GitLab uses dropdown boxes for adding labels.

I think what might be more efficient in this case would be that I had a screensharing session with you to demonstrate how we use Bugzilla and how it is integrated to our other systems. It would also be a chance for me to understand your own aim and angle regarding contributing to LibreOffice. If you are up for this, I would email you to figure out a schedule.

Beluga Beluga wrote:

Claudius Ellsel wrote:

I on the other hand think it's rather perplexing that you think you gave any arguments why GitLab is inferior for issue triaging there. Really, I skimmed through it again and all you wrote seems to be basically quotes of people stating they don't think GitLab can work for large projects (often without even given a proper reason) and I think that you don't like labels (I don't like dropdown boxes on the contrary :), so not really a point, I guess).

So to get this discussion back to facts a bit more, a short list of shortcomings of GitLab from your perspective will work wonders. I'll start with the label based workflow that is extremely flexible on the one hand, but arguably might be harder to use or to reflect all needed tracking options.

I quoted other people, because otherwise it would have been just my word against your hypothesis and I also did not want to spend energy on rewriting everything that has been said. I'm not sure saying GitLab Issues has shortcomings is the right way to put it. It just has a different goal and is not as powerful and flexible as a dedicated bug tracking system.

The problem is that those people merely gave their viewpoints and did not really use reasoning. Thus it is hard to understand their viewpoint for me. I'd argue that GitLab issues are even more flexible than Bugzialla for example. Their way to achieve things is a bit different, though that is correct.

I don't understand your comment on not liking dropdown boxes - GitLab uses dropdown boxes for adding labels.

True :) That was a bit of polemic.

I think what might be more efficient in this case would be that I had a screensharing session with you to demonstrate how we use Bugzilla and how it is integrated to our other systems. It would also be a chance for me to understand your own aim and angle regarding contributing to LibreOffice. If you are up for this, I would email you to figure out a schedule.

I'd love that, thanks for the offer. I guess discussing this and understanding the requirements and viewpoints of each other is much easier that way.

This topic about Wikimedia's move on the Gerrit discussion group is rather enlightening:
https://groups.google.com/forum/#!topic/repo-discuss/w-d3wnPE6rM

For example:
"In one case the migration back to Gerrit started after 4-5 months, and after little over a year the GitLab instance we kept was more or less deserted apart from a plethora of small single-user-repos with utility scripts, example code etc..
GitLab was seen as a great place for playing around and getting things started, but once any serious development and collaboration started the projects were migrated to Gerrit.

• From my experience you will be seen mainly as a monetary opportunity for GitLab and they will do everything in their power to get you into their EE."

This can be considered one piece of experience. I wouldn't call it enlightening for the same reasons you probably wouldn't want me to call the good experiences of GNOME or others as enlightening.

The problem I see with the example is that I don't know what project exactly is talked about and why they decided to use Gerrit again. Technical issues? Management decision? Frustrated users? That would be relevant to extract some relevance for the discussion about GitLab.

The point about problems with contributing features to GitLab and their business model is valid. That is why I suggested an evaluation here. One can also point out relevant features to them and wait until (or whether) they will be made available and only then do a migration.

If what he is talking about the rejected contribution is correct than either the policy has changed in between or GitLab is not telling the truth here: https://about.gitlab.com/company/stewardship/#contributing-a-not-yet-existing-feature. At least to my understanding they say there that they will accept contributions under any license if that feature is not already worked on by GitLab themselves. Also see https://about.gitlab.com/company/stewardship/#contributing-an-existing-feature-to-open-source-it for existing features. There they say that they only had two cases and the reasons for rejection were pretty obvious. But maybe that information is outdated, they encourage users to update it.

For reference, Wikimedia's decision was a topic in Gerrit summit:
https://docs.google.com/presentation/d/1R57-WcvlnuS5J85pLFyCt1Ytc-syeYhCzkfc-6j3AXw/edit
https://docs.google.com/document/d/1fDys8wLXwY914qJSLScV27YOhpP6wMuVDz5zneES2fI/edit