Red Hat bins Bugzilla for RHEL issue tracking, jumps on Jira Red Hat has revealed it’s binned the Bugzilla defect-tracking system for Red Hat Enterprise Linux, in favor of Atlassian’s Jira. “This move allows us to consolidate project tracking into a single place, making the RHEL project in Jira the single source of truth for all development work,” Red Hat senior technical project …
Quite. IME it's not always used correctly either.
At a previous job, the developers (who were allegedly the ones originally pushing to use the thing) seemed to only rarely fill out any Jira fields, beyond the bare minimum like subject/title and maybe who the incident (story, whatever) was supposedly assigned to.
No links to code reviews or other comments or history, just ... nothing.
My only thought was, well heck, the old in-house tool could manage *that*. Why bother....
Most of it has been on Google for years. (I've been resisting mentioning this in public, but I've seen several folks higher than me in the food chain mention or show it lately, so hey).
I don't like this, but it's not new. RH was never 100% open source internally - you just can't convince finance people or some design folks or various other specialists to ditch the proprietary software they're used to - and over the last decade or so it's been fairly systematically moving off self-hosted software to hosted stuff, which tends to be proprietary. We have Gsuite, Slack (*and* gchat, because just one isn't enough pain!), a proprietary hosted wiki-type thing, Salesforce, Workday, all the same stuff you see everywhere.
There was an ongoing argument about this which basically pitted the benefits to the ecosystem (and product development) of attempting to use self-hosted open source at least where it's viable against the perceived benefits to the bottom line (including liability, which is a growing concern the bigger a company gets - there are a ton of regulatory requirements that affect email and messaging systems, which become increasingly onerous to comply with as a company gets bigger) of just making it all Google's problem, and the Google side won. So, hey. That's life.
Bugzilla is kinda caught between two stools at this point. Developers tend to prefer forge issue trackers because they're simpler and closer to the code. Managers don't think Bugzilla gives them enough whizzy reports and dashboards, which Jira is *great* at. So hey, off the deep end with it! Oh, well.
Knowing this, RHEL is clearly shipping components which Red Hat as a company doesn’t use in production for its own infrastructure, like Dovecot. That’s really not a good position to be in, and one would hope management would see the monetary benefit in doing so compared with synthetic testing,
Email benefits so much from economies of scale that it doesn't make much sense for most companies to run their own servers, anymore.
How do you think those economies of scale are achieved? Hint: reduced operating costs to the email hosting company by hiring poorly-trained outsource workers ("You can view email, but not send email? Have you tried rebooting your computer? ...") allow the email hosting company to charge their customers less money than those customers would pay to run their own services ... with the caveat that the email hosting company provides a lesser level of service and customer-facing MTTR. That's how the email hosting company makes their profits.
It's like the Titanic: those virtual (non-existent) lifeboats were cheaper than outfitting the ship with 100% lifeboat coverage, but when the ship hit the ice, the virtual (non-existent) backup plan failed.
(Icon for non-existent helicopter-borne passenger escape.)
RH open source attitude is no a similar to how American companies all pretend they are your family...
Its all fake, no wonder America has Facebook and Google, purveyers of fake advertising and the fake american dream shown in Hollywood. Its turtles all the way down or up or wht3ever it is.
Over 16 reasons why Jira and Confluence suck
Jira is not as good as project management software for managing projects and not as good as bug tracking software for tracking bugs, it's just an event horizon of stupid user interface choices coupled with crazy backend design which makes it impossible to revert mistakes (and we do make mistakes because we're only human after all). Once a company realises their provider or end clients also use Jira then all bets are off, they connect up their Jira instances in the mistaken belief that it will make working with Jira easier and the fail grows exponentially as comments get sent externally that people didn't mean to send and workflows don't match up. The only thing that makes working with Jira easier is ripping it out and using better tools for the job.
As I understand it, Steve was very good at shitting on people, stabbing them in the back, and telling them they're fired. That's what a Junior Exec does, and he was so good at it he became senior exec and eventually chief exec. Stabbing and shitting his way up the stinking pile of Microsoft Middle Managers.
At that point there was noone left to backstab and the mask slipped.
I wouldn't trust him to clean a toilet, he'd be waiting in there with a dagger
Everything you said still means he had to have some level of power in the first place, which again raises the question how did he ever get his first managerial role, and then manage to impress or win his next step up and so on until he got to the very top. There are many levels between the bottom and top, which means the entire corporate structure of microsoft is broken that someone as bad as Steve manages to best everyone else on his way up.
That, my friend, is called "flogging the horse until the carcass is just a pile of bones." I used Jira back in 2016. That and having to use W10 made my decision to hang up my coding sheets for good a lot easier.
Jira has just one thing going for it and that is this... Jira is better than Wordpress's own bug tracking system. Finding a bug to quash is even worse than with Jira.
Jira might be awful, but the requirement was: “be better than Bugzilla”, and it meets that.
No tool is immune to bad process, but you’re right that Jira seems have a lot of one-click features to enable anti-productive processes (merging customer and developer issue trackers is one such).
But I used to work at a company that used Rational ROSE. Remotely Hosted. Via an RDP server. On a different Continent. Jira’s UI holds no terror for me.
Jira is useless for managing projects, like MS Project is useless for tracking issues and bugs.
Jira is reasonably good at what it was originally intended for (issue management), until the Pointy-haired Boss insists that all the permissions and workflows are locked down so nothing ever gets progressed to closure.
Jira can do Agile and kanban, but there are better tools for that.
Confluence has gone from bad to worse. The aforementioned Boss also decided that allowing everyone in the company to contribute to the Confluence wiki was a security issue and restricted pages to certain departments. We now use a secret MediaWiki instead.
The company standard build server is Atlassian Bamboo which is OK, but we were never given enough licences, so we use secret Jenkins servers instead.
Bamboo is terrible. Push a branch and a build fails, theres no rebuild link next door, you have to go hunting...
There are basically zero useful links to do stuff, on any of the main pages. The organisation and links are terrible. If someone tried to do a worse job they woul dhave a hard time.
I am a Red Hat user both at work and personally, and have been for many, many years. I have many years of experience with Bugzilla and JIRA. I have been through a few Bugzilla-to-JIRA transitions. I can only regard them as complete madness.
The "suckage" link above is good, but it's mostly about UI/UX (not only). JIRA was apparently created by people who don't understand SW development and failed - or never took - data structures at college. The most important (the only really important?) relationship between tickets is what blocks what - that determines a partial order. The appropriate data structure is a tree (or, more generally, a lattice). Bugzilla, with a simple plugin, allows one to view the dependencies graphically, as a tree, which is immensely useful. JIRA diesn't - I've been looking for years for the feature since it is so useful.
Bugzilla search and filtering is a lot saner, too. Usually no quasi-SQL queries are involved (not a big problem for me, but too often I've seen managers ask developers to create and save useful JIRA queries).
As the above link mentions there is no real difference between tasks, bugs, stories, etc. They are all things you need to do. The workflow is exactly the same. They can't really be treated differently by anyone. Inexperienced product managers often decide to make features to be developed "tasks" and bugs to be fixed - "bugs". They can't avoid mixing them, however. E.g., one can't prioritize them separately: for each new release there is a bunch of features and a bunch of fixes that customers are waiting for that will consume the same (human) "resources". If any need to be deferred or discarded - which?
And it what may be the biggest (or at least most annoying) workflow problem of all (if it was mentioned in the UI/UX link I missed it): both Bugzilla and JIRA notify you of changes/comments/etc. by email. So you get an email and see someone's comment - what do you do? With Bugzilla you can just reply to the rmail you've just got, keeping the necessary context, and your response will appear as a comment in the ticket. If you send a mail to someone or a group of people, even customers, that is related to a ticket you can just Bcc Bugzilla and add the ticket number in the subject you mail will appear as a comment, etc.
With JIRA you need to switch the interface (between mail and web), possibly more than once, just to react to a comment. In my case, since I work mostly on Linux (yes, mostly Red Hat), but for reasons of "organizational compatibility" (compatibility done backwards, of course) I do mail and some other administrative tasks on a Windows VM I need to switch VMs, virtual desktops, etc. Terrible waste. To be fair, you can email JIRA and make some garbage appear as a comment, but it will be malformed garbage. I have tried using JIRA's markdown to improve formatting - it didn't work.
In short, while it is possible that Red Hat can make it work with a tonne of customizations, etc., I think they are still mad to make this move. Or maybe just not forceful or effective enough to LART some sense into their IBM-minded bosses. Disclaimer: I am a former IBMer as well, and I did run undeclared team/department git and Bugzilla servers there. Well, before JIRA was a thing you could use. Besides, maybe it was just easier in Research.
There is an argument for different issue types.
Bugs - unintended things it does or doesn't do.
Changes - things it's not intended to do, that we now want.
Builds - an actual build of the software, linking to all of the Bugs and Changes that should be fixed in it.
I find it very odd that Builds aren't a native feature of Jira. Or that subissues cannot be in different sprints - thus defeating the entire purpose of dividing something into subissues.
Or... the list is very long.
I've never liked Bugzilla which looks like it was designed to force someone to make it look better.
I've not used Jira much but find it too much for issue tracking, which is all many people need.
Confluence is probably the worst wiki tool I've come across and a terrible idea. Documentation is much better use plaintext and build systems like Sphinx + Read The Docs. But the C-Suite will always prefer to buy and seems impervious to the idea of vendor lock-in.
I just wish it supported testing.
There is clearly an assumption that nobody ever does QA testing of issues, as it's totally impossible to track the effort of dev & QA on the same bug, separately.
It all gets lumped together, which makes all the charts meaningless.
The Red Hat bugzilla has been a valuable resource for all Linux admins and devs for 15-20 years.
It's hard to ever imagine a public JIRA instance reaching such levels of SEO and accessibility... although we all know the plan for this will be for it to be a very private resource instead.
/me goes to "Edit Comment" in JIRA and laughs heartily at the incompetence that allows me to be presented with a 200x100px text box.
I was only ever really exposed to Bugzilla as a user once at one of my first jobs back around 2001. At least at that point it seemed like an unusable mess, no positive memories of it. First started using Jira in 2006(I think) and it was really nice for the basic things we needed it for (I'm in tech operations not software dev), though the developers used it too. Have been using Jira (and confluence) ever since across every job(the solutions were always in place before I was hired).
Though it is true that IMO the Jira/Confluence UI has gone crazy over the past 5-7 years(maybe more, I lost track), for me mostly negative feedback. At least they seemed to have stopped their original plans for trashing the "legacy editor" on confluence. For a couple of years they were really marching towards that saying everything had to be migrated, even when the new editor didn't work well(and still has some glaring issues today that remain unfixed especially with table auto sizing which worked fine by contrast on the old editor). My favorite version of confluence was I think v3 ? The last one where you could still edit the wiki markup.
At my last gig at one point the management tried pushing for this "kanban" board BS, which was just a waste of time and fortunately died on it's own pretty quickly.
I use Xwiki at home which is pretty good.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
