4 ms·

No! You slash the number of bug reports. The bugs are still there! Am I missing some joke here?

by gspr 4y ago

KingOfCoders 4y ago
1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable. 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not. 3. You seem to think that only the bugs in your bugtracker are there. They might be the minority of bugs in your code. Whenever I increase unit testing in my own code, I find dozens of bugs. I was once in a company that hired students during holidays for explorative testing. Dozens of bugs were found every time. The amount of bugs in your bugtracker depends on how much customers you have, how much they care and how big your QA effort is. It's nowhere the number of bugs in your application. The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code. 4. If you don't want to fix bugs, you don't need to track them.
- matkoniecz 4y ago
  If the closing was was purging of not reproduceable/low quality/useless bug reports then it would be different. Would 10 month old well documented report of critical security issue also would be closed after your purge?
  - KingOfCoders 4y ago
    If you have a critical security issue not fixed ASAP but lying around for 10 months I'd say you have other problems in your organisation than a high bug count.
    - gspr 4y ago
      Maybe it didn't look like a security problem at first?
- gspr 4y ago
  > 1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable. It can certainly be reasonable to close unreproducable bugs. But you said that you habitually come in and close any bug older than 6 months. Those are different things. > 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not. Surely it's important to know that the bug exists even if it's unlikely to be fixed? > 3. You seem to think that only the bugs in your bugtracker are there. Not at all. What makes you think that? > The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code. OK. And? You propose throwing out a list of problems because that list is biased and incomplete? "– My roof is leaking! – Yes, but you're focusing on that because it's easy to see! You should ignore it unless you are also sure that your electrical wiring is sound." > 4. If you don't want to fix bugs, you don't need to track them. With respect, this is absolutely nuts! Knowing of deficiencies in a program can be very, very useful!

No! You slash the number of bug reports. The bugs are still there! Am I missing some joke here?

by gspr 4y ago

No! You slash the number of bug reports. The bugs are still there! Am I missing some joke here?

1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable. 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not. 3. You seem to think that only the bugs in your bugtracker are there. They might be the minority of bugs in your code. Whenever I increase unit testing in my own code, I find dozens of bugs. I was once in a company that hired students during holidays for explorative testing. Dozens of bugs were found every time. The amount of bugs in your bugtracker depends on how much customers you have, how much they care and how big your QA effort is. It's nowhere the number of bugs in your application. The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code. 4. If you don't want to fix bugs, you don't need to track them.

matkoniecz 4y ago
If the closing was was purging of not reproduceable/low quality/useless bug reports then it would be different. Would 10 month old well documented report of critical security issue also would be closed after your purge?
- KingOfCoders 4y ago
  If you have a critical security issue not fixed ASAP but lying around for 10 months I'd say you have other problems in your organisation than a high bug count.
  - gspr 4y ago
    Maybe it didn't look like a security problem at first?
gspr 4y ago
> 1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable. It can certainly be reasonable to close unreproducable bugs. But you said that you habitually come in and close any bug older than 6 months. Those are different things. > 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not. Surely it's important to know that the bug exists even if it's unlikely to be fixed? > 3. You seem to think that only the bugs in your bugtracker are there. Not at all. What makes you think that? > The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code. OK. And? You propose throwing out a list of problems because that list is biased and incomplete? "– My roof is leaking! – Yes, but you're focusing on that because it's easy to see! You should ignore it unless you are also sure that your electrical wiring is sound." > 4. If you don't want to fix bugs, you don't need to track them. With respect, this is absolutely nuts! Knowing of deficiencies in a program can be very, very useful!