> No, it's a method of automatically discarding valuable information.
So.. a filter.
I didn't claim it is a perfect filter. I did claim it is _a_ filter and one may subjectively decide it is a better choice than trying to track an ocean of issues which, if you're someone the size of Mozilla, will be a vast majority of "It crashed" useless issues anyway.
_If_ something is that important, it will come up again and closed issues can be referenced. Again, no claim that this is perfect from me.
No, it's a method of automatically discarding valuable information.
To put a different spin on what TeMPOraL said: a bug is roughly defined as a deviation from expected program behaviour. It is not defined as a deviation from expected behaviour which we intend to fix soon. There is value in keeping track of all the bugs in a codebase, even the ones you don't intend to fix soon.
That is to say, a bug tracker is for tracking bugs. It is not a to-do list. (edit Although I wouldn't want items on my to-do list to expire without my knowledge, either.)
If you want to mark a reported bug as Not a bug or Won't fix, that should be done manually. If a bug was fixed in passing as a result of some other work, the bug should be manually marked as fixed. It doesn't make sense to have a timeout act as a stand-in for a triage decision, in a way that fails to distinguish between these two outcomes.