<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - Migration to GitLab or a similar service" href="https://bugs.documentfoundation.org/show_bug.cgi?id=126818#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - Migration to GitLab or a similar service" href="https://bugs.documentfoundation.org/show_bug.cgi?id=126818">bug 126818</a> from <a class="email" href="mailto:claudius.ellsel@live.de" title="Claudius Ellsel <claudius.ellsel@live.de>"> Claudius Ellsel</a> <pre>Oh, I noticed I did not use the word "inferior" correctly in <a href="show_bug.cgi?id=126818#c2">comment #2</a>. (In reply to Buovjaga from <a href="show_bug.cgi?id=126818#c3">comment #3</a>) > 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: > <a href="https://mail.kde.org/pipermail/kde-community/2019q3/005446.html">https://mail.kde.org/pipermail/kde-community/2019q3/005446.html</a> > "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: > <a href="https://mail.kde.org/pipermail/kde-community/2019q3/005450.html">https://mail.kde.org/pipermail/kde-community/2019q3/005450.html</a> > "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: > <a href="https://mail.kde.org/pipermail/kde-community/2019q3/005444.html">https://mail.kde.org/pipermail/kde-community/2019q3/005444.html</a> > "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: > <a href="https://mail.kde.org/pipermail/kde-community/2019q3/005460.html">https://mail.kde.org/pipermail/kde-community/2019q3/005460.html</a> > "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: > <a href="https://github.com/mozilla/bugbug">https://github.com/mozilla/bugbug</a> 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: <a href="https://bugzilla.mozilla.org/">https://bugzilla.mozilla.org/</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>