Mozilla 1.0 Development Process
Friday March 1st, 2002
mozilla.org drivers have posted the plan for the road to 1.0, and how the tree will be managed. Basically, the tree will be under driver control for the entire time following the 0.9.9 branching, which is occurring right now. Large landings will have to be placed on the Patch Landing Tool so that firstname.lastname@example.org can know what will be going into the tree, and when. Click the Full Article link to get the whole scoop.
* link toolbar led to a 5% page load regression
Is this why the link toolbar disappeared? Are they any plan to resurrect it? I thought it was a cool feature..
#2 Re: Re: Re: Hard bug? Why?
Friday March 1st, 2002 7:25 PM
The link toolbar isn't gone and the page load time regression is fixed. View|Show Hide|Site Navigation Bar. It's still there. It's just not enabled by default since it still causes a few percent performance hit on startup and new window times.
Mine is set on "Show only as needed", and I haven't seen it in ages. There used to be a lot of sites where it popped up (I've forgotten now which ones). Do you have a site that should definately display it?
#4 Slashdot displays it all the time
by TonyG <email@example.com.Yuk>
Saturday March 2nd, 2002 3:33 AM
Slashdot displays it all the time
Mine *was* set as "Show only as needed". Somewhere along the line it got reset to Hide Always. I set it again and it works fine. :-)
#7 Re: Re: Re: Re: Hard bug? Why?
Saturday March 2nd, 2002 9:31 AM
I had the same thing happen and I know I never touched it. It was something that happened between nightly builds.
#10 Re: Re: Re: Re: Hard bug? Why?
by choess <firstname.lastname@example.org>
Saturday March 2nd, 2002 11:31 PM
FWIW: the toolbar is being rewritten in XBL (see bug 102992), which is a rather long-term project (hyatt has to provide some more custom DOM events, AIUI). Once that\'s finished and the UI issues are sorted out, we should be able to enable by default.
#11 XBL... DOM events... Hyatt...
Sunday March 3rd, 2002 9:08 AM
If only Hyatt didn't fall in love with OSX....
#13 Re: XBL... DOM events... Hyatt...
Monday March 4th, 2002 11:47 AM
> If only Hyatt didn't fall in love with OSX....
Why should it matter what he's fallen in love with? In a managed software project he'd be spending his time on what the project needed, not on his latest infatuation. Right now what it needs is bug fixes, footprint reudtcion, and performance improvement. So I have to assume that's what he's working on.
#14 Re: XBL... DOM events... Hyatt...
Monday March 4th, 2002 11:54 AM
Pretty lame try of trolling.
#15 Re: Re: XBL... DOM events... Hyatt...
by choess <email@example.com>
Monday March 4th, 2002 11:04 PM
> Why should it matter what he's fallen in love with?
Because he's not only a valued Netscape employee, he's also an energetic and creative contributor of code in his own spare time.
> In a managed software project he'd be spending his time on what the project needed, not on his latest infatuation.
If by "managed software project" you mean "project where companies dictated everything their employees did, ever", you would be correct. Fortunately, this is not the case. > Right now what it needs is bug fixes, footprint reudtcion, and performance improvement. So I have to assume that's what he's working on.
Which he is presumably working on in his capacity as a Netscape employee, as which he undoubtedly has a list of bugs to work on and a manager to report to. The fact that he's working on Chimera as a private individual is not particularly germane to this, although it's relevant to the original topic in that his spare time is going there rather than to XBL/DOM improvements that would help the link toolbar.
#19 Re: Re: Re: XBL... DOM events... Hyatt...
Tuesday March 5th, 2002 12:44 PM
Well, it occurs to me that there is a way to know what any particular contributor has been doing, using Bonsai. Here is a query that will return all of David Hyatt's checkins on any branch in the last month: <http://bonsai.mozilla.org…e=&cvsroot=%2Fcvsroot>
They appear to be almost exclusively Cocoa (Mac OS X) work. No bug fixes or performance improvements seem to be listed except on the Cocoa build.
#20 Re: XBL... DOM events... Hyatt...
Tuesday March 5th, 2002 2:15 PM
I don't know (or care) if Hyatt has fallen in love with OSX. I think that since (a) the Macintosh is one of the three "officially" supported Netscape platforms <http://home.netscape.com/browsers/6/sysreq.html> and (b) Cocoa <http://developer.apple.com/cocoa/> is the 'official' native interface on Mac OSX <http://bugzilla.mozilla.org/show_bug.cgi?id=128898> as opposed to Carbon <http://developer.apple.com/carbon/> or Classic <http://www.apple.com/maco…technologies/classic.html> and since (c) Cocoa is faster than Carbon or Classic in Mac OSX, that it was a critical issue (both for stability and performance) that this issue be tackled. This is not just a "new feature" that should be put off. I am glad an experienced Mozilla developer like David Hyatt is responsible. Go Hyatt!!!
#22 Re: Re: XBL... DOM events... Hyatt...
Tuesday March 5th, 2002 2:59 PM
You're mistaken about the relationship between Carbon and Cocoa. Cocoa is for Mac OS X only applications. Carbon is for applications that can run on either Mac OS X or Mac OS 9. Please note that this is also what the links you gave say. As for performance, there is no reason a Carbon UI can't run at a more than acceptable speed on both Mac OS 9 and Mac OS X.
There already being a Carbon-based Mozilla, there's obviously no pressing need for a Cocoa version right away. This is a side project, which may be why it lives at mozdev.org. Meanwhile, Mozilla itself is desperately in need of bug fixes, performance improvements, and footprint reductions as it approaches 1.0. Why am I reminded of jwz saying that when he was at Netscape, the engineers just did whatever the heck they wanted to? Weren't the people across the hall building a robot instead of coding on Netscape?
As I've said before, the most interesting thing to me about this side project, Chimera <http://chimera.mozdev.org/> , is this: "The cross-platform UI will be replaced with native Cocoa widgetry (such as customizable toolbars and a drawer for the sidebar). The plan is to produce only a browser (no other apps!), and to keep the UI as simple and as clean as possible. " In other words, the plan is to completely abandon two critical but controversial architectural features of the Mozilla project, cross-platform UI and an application suite (including mail, composing, etc.) instead of just a browser. It appears that internal opinion within the project may have come closer to the views of those of us who've been raising hard questions about these features all along.
#23 nothing against any individual
Wednesday March 6th, 2002 9:23 AM
I'd like to clarify that my messages are not meant as an attack on a particular engineer. There is a critique in the messages, but it is a critique of the culture of technical management at Netscape. I am not faulting anyone for acting in a way that is in accord with the cultural norms of their workplace. The change that needs to happen is systemic, not individual.
I apologize for any appearance of personal attack -- I can easily see how my careless phrasing might have created that impression.
#24 Fair enough
by choess <firstname.lastname@example.org>
Friday March 8th, 2002 12:49 AM
I'm not really prepared to speak on the overall state of the culture at Netscape, as I don't feel familiar enough with what its employees are doing. I will say that I'm generally uncomfortable with the fact that one company is bearing most of the burden for developing the project, and I'm trying to push for increased commenting and documentation to attract more corporate contributors. Having a more distributed developer base would insulate us better from the vagaries of any one company's attitude. I think we're already starting to attract such contributors (such as Worldgate, which is currently giving us Randall Jesup, Master of Perf, and timeless), but more contributors need to be "growing" into peers, potential module owners, super-reviewers, etc., since the burden of these tasks tends to fall on people who are also expected to contribute large quantities of good code.
One of the major issues discussed at the recent Moz East Coast dev meeting was that post-1.0, people seem to like the idea of moving away from Mozilla as an application suite (i.e., "just like Netscape, but without the branding!") to a more modular style: Mozilla as platform (XPCOM, XPConnect, XUL, etc.) with the browser alone at the core and other apps attached as the user pleases. There are still both technical and social hurdles to be dealt with (slashing dependencies, deciding what does go in the tree/builds and gains the benefits of distribution, testing, and enforced non-breakage), but I think this is ultimately the way to go in broadening our developer base and escaping the "Netscape-with-the-serial-numbers-filed-off" mindset.
#25 Re: Re: Re: XBL... DOM events... Hyatt...
Saturday March 9th, 2002 4:43 PM
Erm, haven't people pretty much all along been saying that it would be relatively easy to produce a browser-only build, and that native wrappers are also possible (c.f. Galeon, K-Meleon)? Why should it be surprising that someone who thinks that this would be a good thing should actually go ahead and do it (just as you have always been welcome to)?
Actually, bug 102992 doesn't depend on anything except me having (a copious amount of) free time, or somebody else taking over the bug to finish it up. (Which isn't to say that, if Hyatt *were* to turn his attention to it, it wouldn't help - Hyatt's God-like XBL abilities would probably polish it off in a matter of hours, where it would take me weeks :) )
Currently I don't have copious amounts of free time - in fact I barely have *any*, since I'm preparing for a new baby due in June, and Mozilla hacking is definitely taking a back seat.
Anyone who wants to volunteer to work on bug 102992, step right up!
This demonstrates again why adding new features late in the project is a bad idea if they're not really necessary. Just look at all the evaluation time that's obviously gone into dealing with the links toolbar since it was thrown in. That time could have gone to dealing with actual bugs.
this had to be done sometime so on the long term it does not matter if any release was delayed by a week or so. In a year nobody will complain but the link toolbar will still be there...
As one of the primary contributors to the link toolbar I'd have to strongly dispute the claim that lots of evaluation time has been wasted on it. My perception is that the total number of people who have done *anything* with the linktoolbar could be counted on my fingers - including the single person who spent about an hour, or less, doing the performance evaluations on it (actually, we know the original 5% pageload regression from tests that would have been run daily regardless of whether the toolbar was there or not - so that piece took *zero* time).
Not to mention that as for me personally, I have neither the inclination or the ability to work on almost any other bugs. All the time *I* spent on the linktoolbar wouldn't have been "better directed elsewhere in Mozilla", it would have gone to non-mozilla projects, if not for the linktoolbar.
It also seems that there's a possibility that the linktoolbar *will* be backed out for 1.0 because it causes a 3% startup and new-window performance hit that can't be fixed in time for 1.0 (see bug 102992 - and contrary to other reports on this thread, that needs nothing from hyatt in particular, it just needs someone with a substantial amount of time to work on it, which isn't me right now unless you're offering to employ me for that purpose).
Will version 1 by any chance include SVG support? If not, when is that planned?
#9 Re: Question...
Saturday March 2nd, 2002 10:18 AM
You can grab a MathML/SVG-enabled build which do allow that - but Mozilla SVG inline support is just not that advanced yet.
What do you consider to be advanced enough? Yes, it doesn't do svg text or smil animation, however all other objects are now supported.
SVG should be included in the move to 1.1 as these are:
"These example show the value of the PLT after the 1.0 release, as we take more aggressive changes in 1.1. Some other recent changes that would have benefited from patch landing management include:
* turning on MathML in the default extensions * client tag revisions for NSS updates * link toolbar led to a 5% page load regression" IMHO