[Libreoffice-bugs] [Bug 126818] Migration to GitLab or a similar service

Sun Aug 11 22:20:21 UTC 2019

https://bugs.documentfoundation.org/show_bug.cgi?id=126818

--- Comment #5 from Claudius Ellsel <claudius.ellsel at live.de> ---
Oh, I noticed I did not use the word "inferior" correctly in comment #2.

(In reply to Buovjaga from comment #3)
> This is not a single opinion.

Sorry for my provoking statement.

> For examples of other voices, from a recent discussion on kde-community
> mailing list:

Unfortunately that is KDE, not LibreOffice, so the opinions might differ (as
they apparently do for GNOME and KDE - although I think that there is a demo
instance running GitLab also for KDE). However, there was some factual
discussion going on and those arguments could also be true for this project.

> The lead developer of Krita commenting on GitLab:
> https://mail.kde.org/pipermail/kde-community/2019q3/005446.html
> "for tracking bug reports it is an _inferior_ tool because it lacks the
> abilities needed to work with large numbers of reports for complex
> applications. It doesn't even have components -- as far as I can tell,
> everything needs to do be done with just one thing: labels."

This is correct and in fact is apparently wanted. So it is not a bug, it is a
feature :). Seriously, I think it is a different way of treating things and
that might not fit every project. However, it is wrong that it generally "lacks
the abilities needed to work with large numbers of reports for complex
applications" - I will elaborate on that below.

> Krita dev doing a more finegrained comparison:
> https://mail.kde.org/pipermail/kde-community/2019q3/005450.html
> "So, what gitlab issues have over bugzilla is a rich text editor and a
> confidentiality flag. What bugzilla has over gitlab issues is reasonable
> solid set of features that help actually tracking and managing the bug
> report. It's not that I'm a huge bugzilla fan, it could be much better, but
> I need those features.

He forgot some aspects like the ability to create follow-up conversations from
specific comments, autocompletion when typing issue numbers, users, merge
request IDs and probably some more making life a bit easier. Also I want to
state that as said above, most of the "lacking functionality" can be achieved
with labels.

> The reason for that is that gitlab's issues feature seems to have been
> designed for the way smaller, internal teams work inside a company, where
> they would create their own issues during development, or create issues for
> tasks they receive from their product owners. It's not designed for
> receiving thousands of end-user reports a year. It's not designed to be the
> public face of a project."
> 
> Kate editor dev:
> https://mail.kde.org/pipermail/kde-community/2019q3/005444.html
> "In our company we multiple times reviewed bug trackers (for migrating from
> Bugzilla), but none actually had a good enough feature set to be considered,
> beside perhaps Jira (which is non-free/open)."
> 
> Another Kate dev:
> https://mail.kde.org/pipermail/kde-community/2019q3/005460.html
> "but I have to agree Boud and Christoph here. We currently use the Gitlab
> tracker at work, for a quite
>  small project, and it doesn't even really scale to that. I think for a
>  free-time kind of project one person does with 200 users and 15 issues
>  reported over 2 years it's fine, but to me that seems to be the use case
>  it targets."

This is your and the KDE peoples' assumption. And it rather sounds a bit
prejudiced. Probably also related to the fact that you are used to different
systems. What is a fact, however is that it is already used for large projects
(like those from GNOME and freedesktop) and most notably GitLab itself. This is
not a project with "15 issues reported over 2 years", but rather a project with
a total of I think 60,000 issues (leading to performance problems when using
the search function, that should also be mentioned). So it has already proven
that it can be successfully be used by such projects.

> Bugzilla is not lacking a Kanban style board, it has had an extension for it
> for years and will ship Kanban as core feature in version 6 - yet,
> LibreOffice development is not done in a way that Kanban boards would be
> useful. I have once asked about it and the engineering steering committee
> decided it would be useless.

Understood. Did not know that.

> Regarding Tags / labels, these are just metadata, which Bugzilla offers
> plenty. GitLab/-Hub do not offer an advanced search that would allow making
> proper use of such metadata. Closest to labels, in Bugzilla we have
> keywords, whiteboard (for free text input) and flags (which we do not use).

I guess they are also not needed that much, because the design is different
from GitLab or GitHub.

> Search is in fact the most concrete part, where the inferiority of
> GitLab/-Hub can be seen. We need the granular search of Bugzilla in order to
> do quality assurance and development in a sane way.

This is possible with labels in GitLab as well. Probably the search performance
will even be a bit better.

> Related issues are offered when filing a new report.

I meant live suggestions when trying to link another issue, so it is not always
needed to correctly remember the issue number, since one can search directly
when typing.

> In addition to the revamp of Bugzilla (where much of the UX work is in fact
> done by a volunteer), Mozilla is developing a system leveraging machine
> learning, which will allow for a certain degree of automated bug triage:
> https://github.com/mozilla/bugbug

I think GitLab already uses a bot for some kind of automation for their
project, but I am not sure, whether it is also capable of triaging.

> If you want to see a preview of how BZ 6 looks like, you can visit Mozilla's
> BZ: https://bugzilla.mozilla.org/

I already did that. I think it is a big improvement to what is offered here
right now, but there might still be reasons to consider a switch.

However I think the biggest reason, why the KDE people in that mailing list did
not want to change was because it might cost them more time to deal with issues
and they want to use that time for development instead. I am not sure, whether
GitLab will cost them actually more time, but I understand their point.
Bugzilla forces the user to give certain information. In GitLab you only have
labels, you cannot force the user to set them and they are also not allowed to
do so currently. So that might cause some more work to triage issues. This
might improve in the future. On the other hand it might also give lower
barriers for the community and users to step in and help with giving
information etc. on issues, since the barrier seems to be lower. That might
save some time then. But it will also increase the interactions on issue
trackers. And maybe there is a slight wish that the current approach decreases
the users wanting to interact, resulting in less work. The KDE people don't
want to involve their users into the development process much. This is a
special kind of workflow and mindset and might also be problematic when
developing "open" software. And there are many projects doing the opposite like
GitLab.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190811/52023bc0/attachment-0001.html>