Get Involved/Issue Reporting/Why not GitLab Issues: Difference between revisions

Revision as of 18:01, 16 December 2022

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. Here is a list of the outstanding issues and blockers:

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) and 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 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 40,000 issues in https://gitlab.com/gitlab-org/gitlab/-/issues.

Users can't add tags to their own issue reports; only developers can, which 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 (it's an EE only feature), and this cannot be approximated with tags. - https://gitlab.com/gitlab-org/gitlab/-/issues/29914.

No way to track "Number of duplicates", and it cannot be easily approximated with tags.

Have to use mutually exclusive tags to approximate priority, type (crash/bug/feature request/task), resolution statuses (fixed/duplicate/intentional/can't fix), "version reported against", and "OS reported against", which is awkward and increases the work of developers and bug triagers because users cannot tag their own issues.

Bulk updates feature is limited due to the above-mentioned lack of metadata compared to Bugzilla.

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 like Bugzilla has (click on the "Graph" text on https://bugs.kde.org/weekly-bug-summary.cgi).

Search doesn't show you the number of search results returned.

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.

Revision as of 21:44, 27 June 2022 view source Ngraham (talk \| contribs) KDEDevelopers, Administrators, trusted 1,802 edits No edit summary ← Older edit		Revision as of 18:01, 16 December 2022 view source Ngraham (talk \| contribs) KDEDevelopers, Administrators, trusted 1,802 edits No edit summary Newer edit →
Line 6:		Line 6:


	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 and 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 track bugs by unique, persistent URLs!		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) and 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 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.		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.