Jeffrey W. Baker wrote:
> I'd add that this can be extremely frustrating for people outside > netscape. There are definitely two kinds of developers in the Mozilla > project: those at netscape who can get r/sr/a in the space of 10 minutes, > and those not a netscape whose work is scrutinized, criticized, > complained about, put off, and finally backed out in the dead of night > without so much as CCing the main author of the code. > The feature was not backed out. All of the code remains checked into the tree. It was simply turned off in navigator.xul. > The link toolbar, the fix to bug 2800, has undergone more revisions and > reviews than most other features that have been committed to Mozilla. It > underwent a relatively formal design process with a lengthy specification > document. The developers put forth over a dozen working implementations > and refinements thereof. This has been going on for most of the Mozilla > Project's lifetime. Yet, the implementation was yanked without any > coutesy to the developers when most reasonable people were asleep. > It caused the single largest performance spike in page loads in months. We have a zero tolerance policy for increasing page load times. I don't care where the patch comes from, inside Netscape or out. If you increase page load times by 5% or more, then you're going to be backed out or have the feature disabled. Period. > After all, the link toolbar endured a gestation period 43000 > times longer than the <tabbrowser> implementation, while both are UI > changes of approximately equal magnitude. > Bad example. I didn't want the <tabbrowser> turned on and still don't. See bug 101973, in which I tried to have it turned off. The <tabbrowser> needs way more gestation time and review, and it should not be turned on right now. dave ([EMAIL PROTECTED]) > -jwb >
