Get Involved/Issue Reporting/Why not GitLab Issues: Difference between revisions
No edit summary |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
GitLab Issues has several features that Bugzilla lacks, such as inline images, drag-and-drop attachments, markup, editing comments, and single-sign-on with your identity.kde.org account. | GitLab Issues has several features that Bugzilla lacks, such as inline images, drag-and-drop attachments, markup, editing comments, and single-sign-on with your identity.kde.org account. | ||
However in most other ways, it is worse for KDE's use case. | However in most other ways, it is worse for KDE's use case. This wiki page lists the outstanding issues and blockers. | ||
The current work being done to address this in Gitlab can be found [https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners/community-support/-/issues/13 here]. | |||
== Moved issues are cloned with no redirection == | |||
When an issue that was mis-filed is moved to a new location, a new clone of the issue is filed at the new location, generating a confusing email that makes it seem like the author created a new issue. The original issue is closed, but remains open for comments, allowing discussion to drift out of sync, and confused users can post comments in the wrong place. The new cloned issue has a new URL, and the original issue shows you a link to the new location, but does not automatically take you there! And if you move the issue back to its original location, still another clone is created! So visiting the original URL will show you a redirect to a redirect, potentially ad infinitum! This makes it impossible to track bugs by unique, persistent URLs! | |||
== Bugs need to be filed against individual repos == | |||
This doesn't map well to KDE software with a single logical product that is split across many repos, such as KDE PIM, Plasma, System Settings, or KWin. A way to solve this is to put these repos into a group and only track the issues there, but then you have to disable the issues for individual repos which feels arbitrary in the cases where a bug is clearly relevant to only a particular repo. Also, it doesn't solve the problem of being hard to find where to file your bug report, arguably making this problem worse because there is no longer a generic "kde" location or catch-all product like "plasmashell" where you can file something if you don't know where else it goes. | |||
No sub-components | == No sub-components == | ||
Tags have to be used for this instead, which makes organization messy for repos/projects that currently have a lot of bug reports which are well-categorized into sub-components (e.g. plasmashell, systemsettings, kwin). | |||
In practice, large orgs that use GitLab seem to end up having people open issues in one central repo to alleviate the above issues, resulting in issue lists that number in the thousands, making it impossible for anyone to find anything due to the lack of structure. For example see the 70,000 issues in https://gitlab.com/gitlab-org/gitlab/-/issues. | |||
== Non-developers can't add tags to their own issue reports == | |||
This increases the burden on developers and bug triagers to keep a tidy organization because bug reporters can't help out with it. | |||
== No built-in way to communicate a "blocking" or "blocked by" relationship in GitLab CE == | |||
Bulk updates feature is limited | This is an Enterprise-only feature, and it cannot be reproduced with tags. | ||
See also: https://gitlab.com/gitlab-org/gitlab/-/issues/29914. | |||
== No way to track "Number of duplicates" == | |||
We currently use this metric to help triage bugs, and our bugzilla bot uses it to automatically bump priority as needed. It cannot be easily approximated with tags. | |||
== Tag soup of mutually exclusive tags are needed to reproduce bug report fields == | |||
Priority, type (crash/bug/feature request/task), resolution statuses (fixed/duplicate/intentional/can't fix), "version reported against", and "OS reported against" do not have their own fields and require different tags or manual work, which is awkward and increases the work of developers and bug triagers because users cannot tag their own issues. | |||
== Bulk updates feature is limited == | |||
The above-mentioned lack of metadata that can only be addressed with tags makes bulk updates impractical. | |||
Bulk updates feature is completely useless for mass use because it can only edit the 20 issues that are visible on one page, and moving to the next page leaves bulk edit mode! | Bulk updates feature is completely useless for mass use because it can only edit the 20 issues that are visible on one page, and moving to the next page leaves bulk edit mode! | ||
| Line 29: | Line 45: | ||
Bulk updates feature lacks basic functionality such as moving issues elsewhere and adding comments. | Bulk updates feature lacks basic functionality such as moving issues elsewhere and adding comments. | ||
No fancy bug number history graphs | == No fancy bug number history graphs == | ||
Click on the "Graph" text on https://bugs.kde.org/weekly-bug-summary.cgi to see an example of this. | |||
== No global templates/tags/milestones/priorities == | |||
They are at most per group (which is also a premium feature, not CE: https://gitlab.com/gitlab-org/gitlab/-/issues/7749), so an org with multiple groups has to keep them in sync manually, which increases the burden on sysadmins and bug triaging admins. | |||
Latest revision as of 18:14, 10 November 2024
GitLab Issues has several features that Bugzilla lacks, such as inline images, drag-and-drop attachments, markup, editing comments, and single-sign-on with your identity.kde.org account.
However in most other ways, it is worse for KDE's use case. This wiki page lists the outstanding issues and blockers.
The current work being done to address this in Gitlab can be found here.
Moved issues are cloned with no redirection
When an issue that was mis-filed is moved to a new location, a new clone of the issue is filed at the new location, generating a confusing email that makes it seem like the author created a new issue. The original issue is closed, but remains open for comments, allowing discussion to drift out of sync, and confused users can post comments in the wrong place. The new cloned issue has a new URL, and the original issue shows you a link to the new location, but does not automatically take you there! And if you move the issue back to its original location, still another clone is created! So visiting the original URL will show you a redirect to a redirect, potentially ad infinitum! This makes it impossible to track bugs by unique, persistent URLs!
Bugs need to be filed against individual repos
This doesn't map well to KDE software with a single logical product that is split across many repos, such as KDE PIM, Plasma, System Settings, or KWin. A way to solve this is to put these repos into a group and only track the issues there, but then you have to disable the issues for individual repos which feels arbitrary in the cases where a bug is clearly relevant to only a particular repo. Also, it doesn't solve the problem of being hard to find where to file your bug report, arguably making this problem worse because there is no longer a generic "kde" location or catch-all product like "plasmashell" where you can file something if you don't know where else it goes.
No sub-components
Tags have to be used for this instead, which makes organization messy for repos/projects that currently have a lot of bug reports which are well-categorized into sub-components (e.g. plasmashell, systemsettings, kwin).
In practice, large orgs that use GitLab seem to end up having people open issues in one central repo to alleviate the above issues, resulting in issue lists that number in the thousands, making it impossible for anyone to find anything due to the lack of structure. For example see the 70,000 issues in https://gitlab.com/gitlab-org/gitlab/-/issues.
Non-developers can't add tags to their own issue reports
This increases the burden on developers and bug triagers to keep a tidy organization because bug reporters can't help out with it.
No built-in way to communicate a "blocking" or "blocked by" relationship in GitLab CE
This is an Enterprise-only feature, and it cannot be reproduced with tags.
See also: https://gitlab.com/gitlab-org/gitlab/-/issues/29914.
No way to track "Number of duplicates"
We currently use this metric to help triage bugs, and our bugzilla bot uses it to automatically bump priority as needed. It cannot be easily approximated with tags.
Tag soup of mutually exclusive tags are needed to reproduce bug report fields
Priority, type (crash/bug/feature request/task), resolution statuses (fixed/duplicate/intentional/can't fix), "version reported against", and "OS reported against" do not have their own fields and require different tags or manual work, which is awkward and increases the work of developers and bug triagers because users cannot tag their own issues.
Bulk updates feature is limited
The above-mentioned lack of metadata that can only be addressed with tags makes bulk updates impractical.
Bulk updates feature is completely useless for mass use because it can only edit the 20 issues that are visible on one page, and moving to the next page leaves bulk edit mode!
Bulk updates feature lacks basic functionality such as moving issues elsewhere and adding comments.
No fancy bug number history graphs
Click on the "Graph" text on https://bugs.kde.org/weekly-bug-summary.cgi to see an example of this.
No global templates/tags/milestones/priorities
They are at most per group (which is also a premium feature, not CE: https://gitlab.com/gitlab-org/gitlab/-/issues/7749), so an org with multiple groups has to keep them in sync manually, which increases the burden on sysadmins and bug triaging admins.