David Hyatt wrote: > 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. > Patches from inside netscape.com get scrutinized and rejected, too. See the LDAP-remoted pref and MAPI bugs, for just two recent examples. I hear about r/sr delays from all sides, too, and I and [EMAIL PROTECTED] are here to help. If you (jwbaker) have trouble getting mail replies from a particular reviewer, do not hesitate to mail us.
> 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. I agree with hyatt (and waterson, and sballard, and probably others) that a 5% regression should be undone or fixed ASAP. It should not be tolerated for more than day. Note that my disagreement with hyatt is *only* that he didn't allow gerv, who checked in the link toolbar, to disable it, or to otherwise fix it quickly. My disagreement is about *who* should do the "back-out", not whether or (within a day's resolution) when. It doesn't matter how long a patch has been around -- if it's not good enough, it shouldn't go in. Yeah, there's lots of old crap code from before the advent of super-review. So what? Two wrongs don't make a right, and generalizing about old wrongs (if the crap code has not yet been reported via bugs, do so!) does not help make the whole codebase better. >> 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. I think that, in spite of remaining bugs, tabbrowser's patch was higher quality. There were no unused JS functions. There was no 5% performance penalty on pageload. I could go on, but my point is not to beat up link toolbar -- I'd like to see it grow into shipping shape, alongside tabbrowser. But Mozilla is not shipping to end-users in a month (it's not geared at end-users directly, ever). I believe Mozilla should foster free-ranging innovation, which means not strangling good but immature ideas in the cradle. Disabling the feature because it regresses performance is not the same as rejecting it forever --nothing is strangled, however frustrating the temporary set-back may seem. Sballard appears to get the difference -- I hope everyone who worked on the link toolbar patch can be as patient. There's a "mozilla1.0" point to make here, as well: we can't hope to finish 1.0 any time soon if we keep adding good ideas like tabbrowser and link toolbar in young forms and then hope to mature them. Getting to 1.0 in the next six months will mean saying "no" to such features. /be
