MozillaZine

Links Toolbar Landed

Wednesday October 3rd, 2001

Gervase Markham writes: "The Links Toolbar from bug 87428 has finally landed, bringing us ever-closer to full support for HTML 2.0. You'll see it in this morning's builds. The auto-show is still in development over in bug 102832. Good places to try it out are Bugzilla buglists, the W3C, htmlhelp.com and many machine-generated manuals or documents, such as the GNU Make manual."


#126 Re: Re: Re: Re: Re: Re: Re: Re: Cool, but ...

by bcwright <bcwright@ix.netcom.com>

Saturday October 6th, 2001 9:36 PM

You are replying to this message

I've certainly been aware of some large software products by major vendors which had significant features added during the beta period though this tends to be early in the cycle or to be relatively minor feature additions if it's late in the cycle.

In any event, you do need to have some point where you can fix problems that exist in new features or in interactions between features without having to deal with problems introduced in new code (other than the code to fix the problems). Note that ANY new code can generate new errors -- including code that just attempts to fix another error (why do you think fixes are sometimes backed out of the tree?). Some of this is already being done during milestone freezes, more during the more extended branches and freezes for Netscape releases. The problem is that there are still an awful lot of bugs in bugzilla that really are significant errors: For example, there's currently over 80 (!) bugs in bugzilla that are reported to be crashes and that are targetted to be fixed before 1.0, and that doesn't even include any that aren't targetted for releases past 1.0. This number has been slowly drifting upwards - a couple of months ago it was about 60. Now of course some of them are likely to be unrecognized duplicates of bugs that were already fixed, or reports that are simply incorrect (WORKSFORME) or that have always been in the product but have just been found. But these are some of the most visible types of bugs, it's really critical to make sure that they are in fact valid bugs and find some way to fix them. Granted that it's most likely impossible to find and fix them all, this trend is not good. There ought to be a greater effort to reduce this number before adding more features. Generally too it's better to get rid of as many existing, known bugs as possible before adding very much new stuff - otherwise you can very quickly get yourself into a testing and quality control nightmare.

As far as the end-user experience goes, there are still a lot of crashes that I encounter in my usage pattern. I think it's significantly fewer than NS4 at this point, possibly even fewer than IE5.5. (For some reason my usage patterns seem to exercise browser bugs ... lots of people seem to think IE5 is a pretty stable browser but I find it crashes with disturbing frequency). I really DON'T feel I have a completely adequate browser at this point from either Microsoft or Netscape - both of them are buggier than a roach motel. But that's a whole other topic; and I don't think you'll win a lot of new users by just having DIFFERENT crashes than IE (!!).

And this is just the crashers ... there are lots of "significant" bugs that don't actually "crash." That doesn't mean that those can be ignored, though they may often be less visible than crashers. To end on a lighter note, one of my favorite expressions I've heard about adding things to softare products is "New and better FEATURES for new and better BUGS!" But it's not just an amusing comment, it's actually a telling comment about software development.

--Bruce