Fun story: Whilst at The Ohio State University, I was looking for something to do over the summer. Some days were spent driving, and some were spent manning the UNIX Consulting desk in the computer lab. I needed something to pass my time in the latter case.
I had just taken a 1-quarter course in Perl, and so started looking around in that area. I forget exactly how I chose to work on Bugzilla, but that’s what I did.
It was mailing lists, IRC, the Landfill, and our own area of b.m.o. I puttered around, doing some small things and being an annoying college kid. (Hi Frédéric!)
Thanks to that work, Joel reached out to me. He was looking for someone to take over the Bugzilla install that was being used for internal development and external/customer support at Mindspeed. That’s what brought me out to SoCal, where is remained until the company’s collapse and acquisition.
When I was using Bugzilla, I was always unhappy with its "clunkiness". However, since I was forced to migrate to Github and Gitlab, I sorely miss proper sorting on multiple columns and the ability to select the necessary columns for display. I also miss simple JS-free interfaces that don't get in my way (looking at you, Jira and all others, I guess).
I remember 12 years ago, when we were just starting out as a remote company in a world that looked like it had a single digit number of those. We heavily borrowed from Mozilla since most of their process was (maybe still is) out in the open, largely in Bugzilla. Quite impressed they resisted the pressure to move towards something more shiny now that other tools have mostly caught up.
Obviously you're kidding as Jira today is really fast and insanely useful. They're not really comparable though. Jira has much better UX and is designed for 50 different things. Bugzilla is mostly designed for one thing but is extensible, so if you spent 3 years coding you could maybe approach Jira's functionality in Bugzilla
I've never used a 'fast' version of Jira at any company I've worked for recently, self-hosted or cloud.
Search is atrocious.
UX is awful. It's 2023 and whatever version I'm using, it still doesn't accept markdown properly. And it's wysiwyg mode is broken most of the time too - try selecting text and setting it as code/preformatted and the entire comment, or description changes instead.
It's a jack of all trades, master of none.
It's funny, because I was one of the first adopters of it for Megabank, back in the early 00s, because it was fast (flat ui on top of our own Sybase instance), and its UI was simple.
I remember a colleague attaching a screenshot of the text of a JIRA ticket to a ticket, and setting the ticket text to "read the text in the screenshot". Turns out JIRA crashed when he tried to save a ticket with a long text, with the text box deactivated so he couldn't copy it. His solution was to screenshot the text and use it instead of risk losing it.
I've used Jira at three different companies. A high-priority item during my first few days at any new instance is (re)creating a handful of "where the fuck did I see that?" queries to help me find things. Because Jira search is not intuitive, nor helpful.
I have no idea. I haven't used bugzilla in many, many years.
I'd be happy for neither though. Markdown's origins were such that you could write plaintext files that could not only be easily converted to html or some rich format, but were easy to read as-is.
Displaying the plain-text of an issue in fixed-width font would be fine.
Fast? You seem to be serious, but I definitely wouldn’t say jira is fast.
Is the UX really that great? My company has rules about what needs to be filled out before a ticket will appear in our board, but there are so many different things that it is easy to skip one. But there is no indication in the ui of what is required versus what isn’t. It happens often enough that I’d say my user experience with jira is just short of rage inducing.
I have same problem, I found out I can just clone existing issues, then remove the linkage to old issue. It's not perfect but at least I don't have to memorize what things I have to fill. You can find the clone feature by opening existing issue and then "..." button at right corner.
It would be hard to make it faster, considering all the dynamic elements it has to load. The only trade off I can think of would require massive amounts of memory and lots of prefetching and background polling
The Jira I'm familiar with may be extremely powerful, but fast it certainly is not. I also rarely need that power which comes with non-trivial complexity.
>Obviously you're kidding as Jira today is really fast and insanely useful.
That is an interesting comment. Did Jira made some fundamental changes? Or was it really fast as in comparatively speaking to its old self when it was insanely slow?
I like Jira. The UX is good, allows for easy editing and customization. Then Jira Query Language enables good filtering and using it as a back end for custom front ends.
In my eyes it's like a phpMyAdmin specialized for ticketing with an interface which is good enough to not be annoyed when dealing with it.
Bugzilla is literally a cgi-bin Perl script where everything you do is a new page load.
Jira has tons of interactive responsive menus and time saving conveniences. Every month it gets faster and easier to use in some way. You can be way more productive and get work done faster.
Jira itself may be fine, but the people that run your company's instance are almost guaranteed to be certifiably insane. Other comments here spell out why. This is one area where its super-flexible design works against it.
>You can be way more productive and get work done faster
You get less work done because OCD admins keep adding more and more required fields to tickets and you end up having to spend more and more time on writing tickets. In a less flexible system you wouldn't need to deal with so many mandated stupid workflows that suck time away from actually writing and testing code.
I'm subscribed to a couple of GitHub issues from external projects, and I wish we would go back to private bugtrackers like Bugzilla (or some sort of federated solution). Since with the subscriptions you get the comments via Email before they are deleted/moderated, you can truly tell whats going on. The level of insults, entitlement and useless spam comments ("I need this to!", "What is the ETA?", "If you do not implement this, I'm gonna use something else!") has made it a sad, sad place. But everybody has a GitHub account and typing out your rage is a quick thing to do.
I understand that, but it also causes more honest, valuable feedback given. Organizations can decide if the benefits outweigh the negatives, and in the case of the projects in the article, they decided that low barrier of entry is overall beneficial.
Creating a Bugzilla account is trivial, especially if you're frustrated at the software, but it might be a barrier to entry for some positive contributors.
Unless you're proposing to keep the bug tracker only accessible to the core team, and that would make things harder for any external contributors.
I was hoping to find the list of at least 3 oldest bugs, that probably are close to 25 years old too. And a promise to finally fix them, as a part of celebration.
Mozilla is using a mix of Bugzilla, Jira, Github Issues, and $DEITY knows what else, depending on the team or project in question. A good rule of thumb is that for any major system (code hosting, bug tracking, chat, wiki, CI, etc) Mozilla has at _least_ two- one homegrown and/or OSS, another a proprietary service- and a simmering battle over which should be used.
Red Hat is moving to Jira (sadly) for RHEL. However we're still using BZ for Fedora and upstream projects, and likely will be for a very long time to come.
Fun story: Whilst at The Ohio State University, I was looking for something to do over the summer. Some days were spent driving, and some were spent manning the UNIX Consulting desk in the computer lab. I needed something to pass my time in the latter case.
I had just taken a 1-quarter course in Perl, and so started looking around in that area. I forget exactly how I chose to work on Bugzilla, but that’s what I did.
It was mailing lists, IRC, the Landfill, and our own area of b.m.o. I puttered around, doing some small things and being an annoying college kid. (Hi Frédéric!)
Thanks to that work, Joel reached out to me. He was looking for someone to take over the Bugzilla install that was being used for internal development and external/customer support at Mindspeed. That’s what brought me out to SoCal, where is remained until the company’s collapse and acquisition.
Good memories!