Important changes in "Issue Tracker" (Bugzilla) for package requests


Previously our bugzilla was set up to use the less than intuitive ‘trivial/enhancement’ for package requests. My logical mind always rebelled at that. This has now been changed thus:

To make a request for a new or updated packages under Importance select ‘Packaging’ and under ‘severity’ select ‘feature’. I believe you will find that previous such request have already been changed.

I always thought is was just bad to label someones request ‘trivial’. But then I’d prefer Bugzilla to “Issue Tracker” since those in Linux that have been working on technical problems for years have been using bugzilla’s for all that time. It is so common that it is part of Linux lingo. Plus I never hear developers use issue tracker it is always bugzilla when we are working.

“Issue tracker” or “bug tracker” identify the tool purpose. Just like you call “forum” a forum.
Bugzilla is an issue tracker

Bugzilla is a web-based general-purpose bugtracker and testing tool originally developed and used by the Mozilla project, and licensed under the Mozilla Public License.
Released as open-source software by Netscape Communications in 1998, it has been adopted by a variety of organizations for use as a bug tracking system for both free and open-source software and proprietary projects and products.

Bugzilla - Wikipedia

Coincidentally, our bug/issue tracker is Bugzilla :slight_smile:

That said just for the sake of accuracy, of course you are free to call it whatever you like best :grin:

1 Like

I tend to disagree here (which doesn’t mean I strongly disagree :wink:). This was the case for years and seems to be now changing because there is more and more tight integration of all development tools in one place: issues tracking, project management, commits management etc.

I may irritate @bero telling there is something GNOME does better than KDE but I also tend to agree this point from here:

What GNOME does better

GitLab. KDE uses a mix of tools such as Phabricator, Bugzilla, CLI tools, Travis for CI, etc. For us, switching to GitLab (or any tool that would integrate everything into a single tool as good as GitLab) has been a massive win both in sysadmin maintenance and in development workflows.

Gitlab here is just an example, can be Github also. Of course I am not strongly against Bugzilla neither, but I was interested to study @TPG’s proposal to examine the Github Issues alongside with Github’s project management (or which are tied to Github’s Issues.

1 Like

Let’s be sure that everyone remembers that all that has been changed is:


Post-edit: This was important to some people in developer group.

I’m moving this to QA forum. The issue seems to have come up again.

Whether anything here makes sense today I’ll leave to other people. Do we need to change something?

Well sorry I did not come on this topic sooner.

As requested by Colin, I’ll first update bugzilla to latest release.

IIRC this topic is postponed because of the discursion related to the possible migration from github to gitea with github being only rescue mirror.

I’m quite late on it but trying to finish these tasks asap :slight_smile:

1 Like

FWIW It may well be a good thing to handle rpm/package requests a different way and/or in a different place.

When this was originally set up as I recall it was devs that told QA to create a “special” category in bugzilla for package requests. I believe this was sometime in 2013 or 2014 and probably did not get written anywhere. Just a discussion on IRC and we did it.

The more I’ve thought about this the more it makes sense to separate software bugs from Packaging. Perhaps Packaging requests could go here.




Still need to ask devs for what they prefer.


I’d like it!


Formally a package request is NOT a bug.

I don’t like very much them flooding issue tracker system tbh.
If a package request is not satisfied for whatever reason the “bug report” (bug report??) cannot be closed as RESOLVED/FIXED (resolved? fixed?) and we may get a long or short list of “bugs” still open/not “solved”.

In short, one can easily realize that not even the terminology is properly fitting :stuck_out_tongue: