“You’re not making a useful distinction.”
The distinction is useful in the way that fixing the problem doesn’t require getting new people with the appropriate skills.

No one denied whether there was a bug, but there is/was a question of who needed to fix what. Incorrect analysis happens, sure, but you need clear explanations in the bug to make things right. We didn’t get those.

“I’m not arguing about anyone’s lack of critical thinking skills in any regard. I am arguing that they are not used as often as they should though.”

You’re not making a useful distinction.

@chris, bug fixes can go in maintenance releases, no Fx 3.1 required.

A maintenance release of what? Gecko releases have always been defined by browser releases. In order to get a branch with the fix, there would currently need to be a corresponding Firefox release.

– Chris

For this particular case, there was no complete analysis of the impact of the bug and it didn’t affect Firefox, so the default was not to block on this — given the lack of time and the small risk of the bug being major, there was no reason to delay — I understand the need for quick decisions as the release approaches.

The fact that the incomplete analysis was used as a basis to downplay (and even deny) the existence of a bug is where I think the problem lies. Resorting to general statements like ‘if it doesn’t break Firefox, we’re not slipping’ didn’t help one bit either as, from what I gather, this was *not* the actual reason for the non-blocking status.

I’m not arguing about anyone’s lack of critical thinking skills in any regard. I am arguing that they are not used as often as they should though.

The debate on severity essentially started after some people raised the possibility that the basic assumption was wrong, not as a result of estimating the risks from a release point of view.

@alex, you might also argue that the Gecko community could fix a keyboard shortcut that is really important to them in a 1.5 year period, even if it isn’t their fault.

I don’t think any Mozilla contributor lacks critical thinking skills. The bug was never resolved, so the debate centered on severity.

When the one argument for rejecting a blocking status basically amount to ‘it’s the applications own fault, they should fix their code’ after only superficial analysis, one has to wonder if things couldn’t have been handled in a better way.

Personally, I applaud some of the most knowledgeable contributors who actually use critical thinking when it comes to bug fixes/release criteria instead of treating everything as black & white. You might argue that these people have more time to do that than the release people, but I don’t think that’s the core of the issue.