Koko in KDEReview

Alexander Semke alexander.semke at web.de
Tue May 4 19:57:19 BST 2021

On Dienstag, 4. Mai 2021 18:09:53 CEST Nate Graham wrote:
> * Far simpler interface means that it's harder to get confused and
> accidentally add information in the wrong place
> * Inline images makes it much easier to describe a bug visually compared
> to BZ where images are attachments that you have to go out of your way
> to view in another tab or whatever
> * Being able to edit the text allows for the correction of typos and
> adding additional information rather than useless extra comments
> * Mentioning an issue in another issue automatically creates a link to
> it, rendering the "See also" feature of BZ obsolete and removing the
> manual chore of having to manually link issues
> * Tighter integration with the GitLab Merge Request feature without the
> need for a fragile bot
> * Tighter integration with other GitLab features such as milestones
> * Many more "closes X" keywords are accepted, reducing the chance that a
> merge request will try to close a bug report on merge but fail due to
> not getting the syntax quite right
> * Per-project templates
> * One fewer dedicated service for our overstretched sysadmins to host
> * Responsive upstream
> * Possibility of improvements over time
Jira can do all of this, except of the tight integration with GitLab out of
the box maybe, and even more. I'm heavily using Jira at work on the daily base
and it's a very reliable and feature-rich tool for project management and
issue tracking. Many open source communities are using Jira, also Qt.

> I could go on for longer if you want, but this is just what I came up
> with after a few moments of thinking about it. I won't pretend that GLI
> is perfect, and there are unresolved questions regarding how we would
> handle something like the "plasmashell" product that aggregates bug
> reports for user-facing components that live in many different repos.
> The search is less powerful too (though much faster). But let's all try
> to have an open mind. I don't think we'll get anywhere if anyone says,
> "no way, no how, never ever, over my dead body."
If we try to have an open mind and are also ok with closed source software
that is offering its service for open source projects, should we consider Jira
as well?



More information about the kde-core-devel mailing list