3 ms·

> And how do you address my point that the volume of so-called "unimportant" bugs I would address your point by first re-focusing our attention on the basic an

> And how do you address my point that the volume of so-called "unimportant" bugs I would address your point by first re-focusing our attention on the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand, so just grasping that again as part of the conversation seems to be necessary. So, you asked about the "so-called" unimportant bugs? Yeah, they're called that because they're the unimportant ones. It sucks if an unimportant bug bothers you or interrupts your workflow - been there. If unimportant bugs still seem important to you, an easy way to understand this concept is that in comparison, other bugs exist that are deemed even more important than these. And the company developing the software in question gets to make this call. > a myriad of small, nearly-meaningless bugs ... pile up until your product is noticeably full of them. I don't think that is at all how this works. There are numerous bugs and errors in software that have no real effect on users. Could they be fixed? Sure. But having 10 of these (your words) "nearly-meaningless" things still results in ... near-meaningless. If they had meaning and were important, people would be complaining so much about it that you couldn't sweep the issue away by auto-closing a dead 2-year-old ticket. > Google is constantly, constantly, constantly, constantly adding new features. Correct. It is what people/users seem to like and want. Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on? > Worse, they've obviously chosen to auto-close bugs that they've ignored They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important. When that happens, important things don't get handled. If the bugs being auto-closed were important, users would be clamoring about it, discussing the issue, and opening tickets with support. When one developer with a hawk-eye for errors drops a new bug/suggestion, it isn't going to get the same attention as a huge file-deletion bug in the new feature that just rolled out and is being actively used. > I don't know whether they do that anymore, but the point is that Google has plenty of time to do stuff. Again, even big companies do not have infinite resources. Just jumping to the conclusion that they're big means they should be able to do everything tells me there is a lack of experience speaking an opinion here.

lapcat 1y ago
> the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand This is nonsense. I don't agree at all. The meaning of "important" and "unimportant", with respect to any particular issue, is vague, controversial, arguable. It's ridiculous to suggest that we can easily put bugs into those two categories. > There are numerous bugs and errors in software that have no real effect on users. This is also nonsense. If there's "no real effect", then there's no bug. > But having 10 of these (your words) "nearly-meaningless" things What are you claiming to be my words? > It is what people/users seem to like and want. More accurately, what stockholders/advertisers seem to like and want. > They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important. That's nonsense, and not how it works. In fact the Google bug tracker has a specific "Priority" label for each report. You don't need to close a bug report to assign it a priority. > When that happens, important things don't get handled. That's not true either. Not all open bug reports get "handled". > When one developer with a hawk-eye for errors drops a new bug/suggestion 1. I didn't drop a suggestion. 2. I didn't have a "hawk-eye for errors". I'm not specifically looking for bugs in Chrome. I have absolutely no desire to do free labor for an ultra-wealthy mega-corporation. I was simply using the developer tools, and they didn't work right. > Just jumping to the conclusion that they're big means they should be able to do everything Another straw man. > there is a lack of experience speaking an opinion here What "lack of experience" are you referring to? I've been a professional software developer for 19 years, how about you?
- leakycap 1y ago
  You might have already seen this, but I thought you'd be tickled to see this bug fixed related to the 1980s Macintosh II in the modern linux kernel: https://www.phoronix.com/news/Linux-6.16-Mac-II-Fix https://www.phoronix.com/news/Linux-6.16-Mac-II-Fix Sorry for not responding to the rest of your message, it's just a low priority kind of thing where I'll probably just respond in 2 years and ask for a system report and then auto-close the ticket.
latexr 1y ago
> It is what people/users seem to like and want. I’ve seen that argument a few times, yet no one has ever been able to point to any tangible proof. Anecdotally, I see people significantly more frustrated by things working poorly than a lack of imagined features no one asked for. > Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on? They should first focus on the bugs to old features that the new features caused. Adding new functionality should never cause a regression to what already exists, but when it happens, those should be prioritised.

lapcat 1y ago

> the basic and commonly understood meaning of the word "unimportant" - the definition is fairly easy to understand This is nonsense. I don't agree at all. The meaning of "important" and "unimportant", with respect to any particular issue, is vague, controversial, arguable. It's ridiculous to suggest that we can easily put bugs into those two categories. > There are numerous bugs and errors in software that have no real effect on users. This is also nonsense. If there's "no real effect", then there's no bug. > But having 10 of these (your words) "nearly-meaningless" things What are you claiming to be my words? > It is what people/users seem to like and want. More accurately, what stockholders/advertisers seem to like and want. > They've "ignored" aka de-prioritized some requests, because otherwise all requests would have to be considered equally important. That's nonsense, and not how it works. In fact the Google bug tracker has a specific "Priority" label for each report. You don't need to close a bug report to assign it a priority. > When that happens, important things don't get handled. That's not true either. Not all open bug reports get "handled". > When one developer with a hawk-eye for errors drops a new bug/suggestion 1. I didn't drop a suggestion. 2. I didn't have a "hawk-eye for errors". I'm not specifically looking for bugs in Chrome. I have absolutely no desire to do free labor for an ultra-wealthy mega-corporation. I was simply using the developer tools, and they didn't work right. > Just jumping to the conclusion that they're big means they should be able to do everything Another straw man. > there is a lack of experience speaking an opinion here What "lack of experience" are you referring to? I've been a professional software developer for 19 years, how about you?

leakycap 1y ago
You might have already seen this, but I thought you'd be tickled to see this bug fixed related to the 1980s Macintosh II in the modern linux kernel: https://www.phoronix.com/news/Linux-6.16-Mac-II-Fix https://www.phoronix.com/news/Linux-6.16-Mac-II-Fix Sorry for not responding to the rest of your message, it's just a low priority kind of thing where I'll probably just respond in 2 years and ask for a system report and then auto-close the ticket.

latexr 1y ago

> It is what people/users seem to like and want. I’ve seen that argument a few times, yet no one has ever been able to point to any tangible proof. Anecdotally, I see people significantly more frustrated by things working poorly than a lack of imagined features no one asked for. > Unsurprisingly, new features come with new bugs... these new bugs may be way nastier than the so-called "unimportant" bugs that have been well-known for a while. Which fix should the team focus on? They should first focus on the bugs to old features that the new features caused. Adding new functionality should never cause a regression to what already exists, but when it happens, those should be prioritised.