Really great use of machine learning! But I wonder why it wasn't called BuggyMcBugface. Perhaps they're saving that name for when they train a transformer model to "translate" bug reports into code commits...
Related, since it's also a Mozilla project, I was shocked to see rust-lang/rust's issue count. I consider Rust to be one of the best maintained open source repositories. Their DevOps is legendary. And yet, the repo has over _4,600_ open issues.
That issue count isn't for lack of fixing things. The Rust project is tirelessly proactive about handling issues, merging pull requests, mentoring committers, etc. I've personally contributed to Rust before and had a splendid and expedient time doing so. In other words, I wouldn't say Rust has 4,600 bugs so much as it has 4,600 coals in the fire.
That's insane. I have a really hard time wrapping my head around the herculean task of triaging and working an issue pool of that size. It really gives me a lot of respect for the team members and volunteers.
I thought it was worth sharing as others may not be aware of just how crazy open source project management can be. It certainly puts tools like BugBug's importance into context.
I have reported 238. 45 have been fixed, 27 I later marked as "works for me" (so fixed by some other change in Firefox). 57 were duplicates of other bugs (and I'm not looking to see how many of those were fixed).
Things do get fixed, but it is a big project with not a huge amount of staff.
If I had more time on my hands this would be okay, but when I'm developing web pages/applications, I end up using workarounds because Firefox is so often not compliant, rather than suddenly becoming a qualified Gecko developer and finding the time to fix some almost-Netscape-era bug.
The problems mount up over the years while it seems that meanwhile, Mozilla has a lot of frills and luxuries on the budget as an organization, when the core product is generally lacking in terms of compliance and quality.
It's frustrating, because I want to like Mozilla, but their browser is the most work to develop for, and the least fun to use (in my case in particular, since Firefox is generally worse on Linux than on Windows).
Added: I'm also frustrated that when I share my personal experience of the process with Mozilla, people won't have it (not talking about _yoasif here, good work on those successful reports!). I get that it's your baby, that you have a personal relationship with Mozilla that makes you want to defend it, but if you love it, you must allow it to face honest criticism, even if at the end of the day you'll choose to ignore it.
I've only reported three, and admittedly one of these is not a very easy report to work with (because I had trouble producing a reduced test case, and I was an obnoxious teenager).
The webpack team has a simple solution: they have a bot that closes inactive issues. The issuer need not keep the issue alive by posting into the issue.
Forwarded this to our internal Red Hat memo mailing list. Hopefully someone will adopt this as we got products with more issues on record than Mozilla.
for what it's worth, I've generally given up expecting anything to happen from my redhat bug reports.
I tried to dig up the original emails, but I can't see them at the moment. https://bugzilla.redhat.com/show_bug.cgi?id=571322 particularly springs to mind. Took 6 years before it got closed, and wasn't really resolved. It took more than 3 years to even be asked a question :)
I've a few others along similar tracks, even cases where I've reported breaking bugs in RedHat, where RedHat were the maintainer that fixed the bug in the upstream kernel, and have the expertise still in house, but the fix hasn't been back-ported.
14 comments
[ 2.6 ms ] story [ 47.0 ms ] threadRelated, since it's also a Mozilla project, I was shocked to see rust-lang/rust's issue count. I consider Rust to be one of the best maintained open source repositories. Their DevOps is legendary. And yet, the repo has over _4,600_ open issues.
That issue count isn't for lack of fixing things. The Rust project is tirelessly proactive about handling issues, merging pull requests, mentoring committers, etc. I've personally contributed to Rust before and had a splendid and expedient time doing so. In other words, I wouldn't say Rust has 4,600 bugs so much as it has 4,600 coals in the fire.
That's insane. I have a really hard time wrapping my head around the herculean task of triaging and working an issue pool of that size. It really gives me a lot of respect for the team members and volunteers.
I thought it was worth sharing as others may not be aware of just how crazy open source project management can be. It certainly puts tools like BugBug's importance into context.
Things do get fixed, but it is a big project with not a huge amount of staff.
The problems mount up over the years while it seems that meanwhile, Mozilla has a lot of frills and luxuries on the budget as an organization, when the core product is generally lacking in terms of compliance and quality.
It's frustrating, because I want to like Mozilla, but their browser is the most work to develop for, and the least fun to use (in my case in particular, since Firefox is generally worse on Linux than on Windows).
Added: I'm also frustrated that when I share my personal experience of the process with Mozilla, people won't have it (not talking about _yoasif here, good work on those successful reports!). I get that it's your baby, that you have a personal relationship with Mozilla that makes you want to defend it, but if you love it, you must allow it to face honest criticism, even if at the end of the day you'll choose to ignore it.
https://bugzilla.mozilla.org/buglist.cgi?emailreporter2=1&em...
They did some housekeeping for a month and were able to close 3918 issues, but in the meantime 2187 issues were created.
Open source project management at this scale is truly hard indeed.
Pro: Train new students to work on real work development processes, issues, teams.
Good for students' resumes.
Con: Not sure if completely legal if it is not pay.
Also might create conflicts with current employees of the company.
I tried to dig up the original emails, but I can't see them at the moment. https://bugzilla.redhat.com/show_bug.cgi?id=571322 particularly springs to mind. Took 6 years before it got closed, and wasn't really resolved. It took more than 3 years to even be asked a question :)
I've a few others along similar tracks, even cases where I've reported breaking bugs in RedHat, where RedHat were the maintainer that fixed the bug in the upstream kernel, and have the expertise still in house, but the fix hasn't been back-ported.