Firefox and the Mozilla Platform
March 4th, 2008
Brendan Eich: “Doing more for other apps by delaying Firefox is not sensible. Neither, of course, is sweeping a bug under a carpet based on hasty diagnosis or wishful thinking.”
I agree with that remark. However, there may be an implication that denying blocking status on a bug means release drivers are denying that a bug exists. I don’t agree with that.
If a module owner is refusing to work on bugs that aren’t blockers, and you think that list is too small, your dispute is with them. Update: by this, I meant bugs that really are severe, but there is a dispute about that. Discussing the pros and cons with the module owner and getting the information in a bug is much better than responding to a blocking- with “but this is wrong!”
Don’t expect release drivers to own the module. In fact, the dispute resolution process leads directly to Brendan. It doesn’t involve the people tracking the progress of the release, who cannot do useful work if they’re continually being asked to second guess module owners.
March 4th, 2008 at 4:17 pm
I don’t recall ever hearing a single person make this argument.
I really can’t understand what’s so horribly complicated about the debate at the moment. If another application, were it to be rebased around the Gecko that ships with FF3, were to have obviously regressed in some manner to the version based around FF2, then this should block. There’s absolutely nothing else that need be discussed.
The original discussion was wholly based around obvious platform regressions and any attempt to obfuscate this should be regarded as dishonest ass-covering.
- Chris
March 4th, 2008 at 4:54 pm
“If another application, were it to be rebased around the Gecko that ships with FF3, were to have obviously regressed in some manner to the version based around FF2, then this should block.”
Nope. Other apps are going to trail Fx3 onto Gecko 1.9, so some bugs don’t need to be fixed for 1.9.0.0. We can pick them up in point releases. So, yes, problems of that sort are *bugs*, but I think there is more flexibility in the schedule to fix them.
March 5th, 2008 at 3:39 am
If Gecko is defined entirely in terms of Firefox (which is what this logic says) then that effectively eliminates the point of versioning Gecko independently at all. Just say that XULapp 2.0 requires Firefox 3.1.
And what is the likelihood that a Firefox 3.1 would be spun fixing a number of Gecko regressions if none of them affected Firefox? Would it actually be the case that no 3.1 would be tagged until something which affected Firefox was fixed, leaving other XULapps again basically hanging on Firefox?
- Chris
March 5th, 2008 at 12:21 pm
I don’t think that the actual decisions are in play here as much as the way they are made.
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.
March 5th, 2008 at 1:26 pm
@chris, bug fixes can go in maintenance releases, no Fx 3.1 required.
@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.
March 5th, 2008 at 3:11 pm
Like I said, I’m not arguing against the actual decisions.
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.
March 6th, 2008 at 4:24 am
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
March 6th, 2008 at 1:05 pm
“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.”
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.
March 7th, 2008 at 10:10 am
“No one denied whether there was a bug”
If you do not qualify some of the comments as denial that there was a bug in the platform, then I guess we don’t have the same definition of denial — there’s no point in continuing the argument on this matter if we’re not even arguing about the same thing.
“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.