Description: Currently bug/issue tracking is separated from code hosting and build servers. Also the UI and UX of Bugzilla is not very intuitive and easy to use, including some lacking features like editing posts etc. Thus it might make sense to consider migrating to a different service like GitLab as some other Open Source projects like GNOME and freedesktop already did. Steps to Reproduce: Obsolete Actual Results: Obsolete Expected Results: Obsolete Reproducible: Always User Profile Reset: No Additional Info:
Bugzilla 6 will have editing posts and better UI & UX. Please see https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-7-Roadmap https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-8-Roadmap GitLab's issue tracking functionality is inferior to Bugzilla. It is unfortunate that GNOME and freedesktop decided to switch to a weaker system. Our code hosting and patch review are already connected with Bugzilla, you can refer to BZ issues with tdf#123456 and automatic comments are added to reports, when commits are made.
> Bugzilla 6 will have editing posts and better UI & UX. Nice to hear! > GitLab's issue tracking functionality is inferior to Bugzilla. Sad you did not give an example where Bugzilla is inferior to GitLab. In general it is based on how you define "issue tracking functionality". There are many fields where GitLab is in fact inferior to Bugzilla (at least currently). Just have a look at Bugzillas roadmaps that you linked. Many of the points are already available on GitLab. > It is unfortunate that GNOME and freedesktop decided to switch to a weaker system. I guess "weak" is pretty subjective here. Both GNOME and freedesktop have done an evaluation and found the system (in general, not only the issue tracker) to be pretty good for their needs. - https://www.fooishbar.org/blog/gitlab-fdo-introduction/ - https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure Some more features that Bugzilla is at least currently lacking: - Kanban style board - Tags / labels - Autocompletion / suggestions for related issues when typing a number Moreover GitLab offers things like online code preview, editing, review and CI tools. Thus it could substitute already used services like Gerrit and Jenkins leading to a more streamlined and effective workflow, better UI and UX also in those fields, less administrative effort and last but not least a lower entry barrier for Newbies or people who just want to contribute a quick fix like correcting an annoying typo etc. Has this already been discussed with the community / the respective decision makers? Then please give a link. For now I will mark this as open again, since I don't consider a single opinion on this as a valid decision.
This is not a single opinion. For examples of other voices, from a recent discussion on kde-community mailing list: 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." 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. 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." 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. 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). 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. Related issues are offered when filing a new report. 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 If you want to see a preview of how BZ 6 looks like, you can visit Mozilla's BZ: https://bugzilla.mozilla.org/
Yup -1 and => WF, BZ and update to 6 is solid for project QA and RFE needs.
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.
Over here at LibreOffice-land, we do not want to reduce the number of users contributing to bug analysis. We can only wish they would choose the right platform from the start (ask.libreoffice.org for questions etc), but there is certainly not a desire to sweep issues under the rug. Bugzilla's outdated UI has made me worry about losing user contributions for years. The problem is very real and it is unfortunate Mozilla did not sync their changes with upstream in a timely manner (years ago). It is also unfortunate that other organisations have not contributed to Bugzilla in order to make harmonisation happen sooner. I can of course blame myself for lack of initiative to push this in TDF & elsewhere. When freedesktop announced GitLab, I contacted Daniel Stone, who maintains the infra and pointed him to Bugzilla 6. He was not aware of the developments and it is possible that the infrastructural decisions would have been different if he had known about them.
(In reply to Buovjaga from comment #6) > Over here at LibreOffice-land, we do not want to reduce the number of users > contributing to bug analysis. We can only wish they would choose the right > platform from the start (ask.libreoffice.org for questions etc), but there > is certainly not a desire to sweep issues under the rug. Good to hear. Just one thing I noticed about the wording: Bugzilla is mostly calling the actual issues "bugs" and also you are referring to it mostly for bug analysis in your comment. This might have an impact on what users think this is for. I remember that I wanted to propose a feature some years ago in a different project using Bugzilla. At first I was a bit puzzled, whether that was really the correct place for feature requests, since everything seemed to be focused on bug reports. Even in this feature request here, I had to fill in the fields for steps to reproduce and so on. This is probably also mostly on Mozillas side, but I wanted to point that out. > When freedesktop announced GitLab, I contacted Daniel Stone, who maintains > the infra and pointed him to Bugzilla 6. He was not aware of the > developments and it is possible that the infrastructural decisions would > have been different if he had known about them. That would have been indeed interesting. I am fine with the way they went and it was also not only because of the issue tracker, but also because they could have all their services in one place (which is also a thing to consider for LibreOffice as I mentioned some posts earlier). That is in my opinion a really big benefit of GitLab. So I hope the decision to stay with the current setup having Jenkins, Gerrit etc. will be overthought. This is a barrier for Newcomers and small contributions. It can also be linked to Bugzilla, if you don't like their issue tracker right now. For now I hope, the development of Bugzilla speeds up a bit to keep up with the other issue trackers from GitHub and GitLab (whose success probably also accelerated the change in some ways of thinking at Bugzilla like comment editing).
How come it's been two years and BZ 6 still hasn't been adopted? Why is this site still stuck to this old as hell BZ installation?
(In reply to mat.venturini from comment #8) > How come it's been two years and BZ 6 still hasn't been adopted? Why is this > site still stuck to this old as hell BZ installation? Because BZ 6 has not yet been released. The release blockers are here: https://github.com/bugzilla/harmony/blob/main/RELEASE_BLOCKERS.md The scope of the release was decreased and it now says "I think most of the postgres incompatibility is in the "BMO" extension, and in order to be able to release I now believe we should remove the BMO extension from our codebase. This is unfortunate because it has a lot of useful features, but given resource constraints it is the best move." Sadly the current volunteers don't have much time to work on this. We have funding opportunities, but the problem is finding capable people to do the work. I am constantly seeking such people and I'm discussing the topic right now with a company.