Tree Closes Tonight for Mozilla 0.9.9Tuesday February 19th, 2002mozilla.org will begin the process to release Mozilla 0.9.9 tonight at 11:59 pm pacific by closing the tree to free checkins. Mozilla 0.9.9 is the last major milestone prior to 1.0, and includes numerous bugfixes in composer, history, and other areas. Along with this, likely new features that will be in the milestone include a new full screen window mode, set image as wallpaper, and composer publishing. Following the tree close tonight, expect up to a week of tree closure for stability and regression fixes, then a branch to be cut some time next week. As soon as the branch is cut, the trunk will reopen for Mozilla 1.0 checkins. mozilla.org is shooting for a March 1st release date, but due to this being the last milestone before 1.0, and because there is a large amount of code that will be landed tonight prior to tree close, delays may occur. So will the bug that makes mozillazine look like unfettered ass be fixed for .9.9 or will I have to keep using the IE stylesheet. I am not shedding any tears for Mozillazine this morning. Too many "database not available" errors. Too many times do I go to the forums and they aren't there, or I have to reload them before they are displayed. I get a lot of database errors on this site, and those look like server-side problems. As for the style sheet, Mozillazine should fix that to make Mozilla look good. Mozillazine is an advocacy site, right? How dare you complain? You've paid nothing for this site and the admin has a girlfriend and umm.. what were the other reasons again? Someone help me out! >>what were the other reasons again? Someone help me out! How about "ordering people around with statements like 'fix this site' doesn't usually produce the results you're after". Seems like a pretty good reason to me. Let's try it and see if it works. Macpeep, send me money now! Write me a poem! Buy a Volvo! Did that work? I'll give you a couple of days on the money (if you look hard enough on the web you can find my address but this is an order, not a request so I don't feel it necessary to actually help you with the task). I'd like the poem, (preferrably a sonnet) by the end of the day. You can mail or post online the photos of you in your new Volvo. --Asa That's the most rediculous argument I've ever heard Asa. We're not ordering him to fix it. We're saying, "look you should fix it for at least one of these very valid reasons." Now if you could give me several valid reasons why I should send you money, write a poem, and buy a volvo to somehow improve someone's perception of a product I'm supposed to be advocating, then so be it, I probably would. It all boils down to this, Mozillazine is the foremost in mozilla advocacy and news, if Mozillazine doesn't render properly in mozilla then it makes mozilla and Mozillazine both look bad. The absurd workaround to make the site render properly is to use the IE stylesheet why in god's name would I use mozilla over IE when the workaround is to use an IE stylesheet that works in both. My proposed fix for this mess is to just use the IE stylesheet for the entire site and get rid of all the problems. So to recap, Asa your argument is bunk, You're losing users every day by not fixing it, and the fix is as simple as changing two lines of html. A post titled "fix this site" is an order, not a reqest, not a friendly proposal about the cost and benefit, not a "we would really like it fixed" request, not a "look, you should fix it" which at least starts off with the reasonably friendly "look". It's a command, or an order and it generally doesn't work to order people around unless you are in some position of authority over them (and even then it tends to not work very well unless you can back it up by withholding money or imposing physical abuse). In this context, where you're a consumer of a free service, ordering the provider of that service with commands like "fix this site" is plain rude. BTW, I'm not losing users. I don't have users. Well, maybe I consider Bugzilla users to be my users but that's even a stretch since Bugzilla (even the installation at bugzilla.mozilla.org) isn't really mine. Also, the fix is not as simple as changing two lined of HTML. You are plain wrong about that. Oh, and one final note, using the IE stylesheet does not make it work because the IE stylesheet has anything to do with IE. It makes it work because it a re-layout of the page where the style sheet is actually loaded. There are solutions to working around bugs in Mozilla (just like working around bugs in IE or any other browser) and I suspect that Mozillazine folks will either work around this bug or work to get the bug in Mozilla fixed. If you're unwilling to wait for either of those patiently like most of the people that visit this site then you're free to get your dose of Mozilla from some other source. I get lots of good information from the newsgroups and the status reports at mozilla.org. --Asa Please fix this site. It looks terrible on Mozilla, largely because of a bug in Mozilla that could be worked around with a different stylesheet. Let's not forget all the database errors. How hard could it be to fix those? Just fix them. Please. #38 Seems like fixing the site would drop bandwidthby theuiguy Wednesday February 20th, 2002 2:47 PM I know people reload the page multiple times to see if the horrible scrunched single column layout is going to correct itself. It seems like those extra hits would be avoided by having a style sheet that actually worked. I do find it a problem that the main Mozilla advocacy site looks awful in Mozilla a good percent of the time. When you load the site and it is all scrunched up, hold the shift key and click reload. It works every time (or has for me). If you are truly a supporter of Mozilla, you\'ll realize that it\'s pre-release software. That is written everywhere. If you want release quality software, go hit up the NN6.2.1 build. Otherwise, find a workaround. I don\'t want to come across as ignorant, or like I\'m trying to cover for the designers of the site. I too get a database error sometimes, or I have to reload the page to view it correctly. I too have gotten frustrated about it. I too have *politely* told people about the problems. However, I\'ve also tried to help out through bugday (still having a little trouble, but trying to get somewhere) and through using a build with talkback enabled, etc. I realize this doesn\'t always help (the problems on mozillazine don\'t crash moz and therefore don\'t generate a talkback report), but its a start. If you want Mozilla to be heavily used and to be \"big time\" try to spend less time arguing about who said what and why and spend the five minutes you used to give a hand (look for a duplicate bug, or better yet, show me how to find them). Its a little more constructive and a lot more helpful to everyone invoved and also helps make a better product for each of us to use. Sincerely, jfournier Asa, I personally have not demanded the site be fixed. You will have to talk to morg about that. I have been trying to show you, the mozillazine admins and anyone else who has the authority, a side of the situation which I'm sure they've thought about but maybe not taken as seriously as they should have. This is the main mozilla news site for end users who are interested in the progress of the browser. Using usenet and the status reports is an unreasonable burden to put on the casual mozilla end user. I'm sure the majority of mozilla users are in fact not developers and would have no idea what anything in the status report actually means. They turn to mozillazine to translate that information into a meaningful context which they can understand. Regardless of whether or not the IE stylesheet has anything to do with IE or not most end users would see, hey it doesn't work with the normal configuration, but it's suggested here to use the IE stylesheet as a workaround, so by word association would assume that means IE itself somehow and therefore use IE instead of mozilla. I don't expect the SQL errors to go away as that has more to do with bandwidth than anything, but my main concern with the site is the fact that it renders improperly in the browser it is supposed to be advocating. I would have thought the SQL errors would be more related to the SQL server's performance than bandwidth. "I would have thought the SQL errors would be more related to the SQL server's performance than bandwidth." You are quite right. But even if your database only allows x amount of concurrent connections, you can very easily set up a queue for those x connections. The code using the database will then block while it waits to get a conncetion, rather than resulting in not getting a connection and having to display an error. The waiting time would be very low or none at all in most cases. Of course all connections would also just be recycled and taken from a pool of connections. That way, the time needed for establishing the connection to the database and logging in is gone. Another way to get rid of the error is to make sure that each generated page requies a minimal amount of database connections. Since the site isn't really dynamic from one second to the next, data could and should also be cached. For example the "read" counts for each user could be fetched when the user first enters the site and then only kept and updated in memory, and be commited back to the database when the user's session times out. Same for posts. The 10 most recently read article comments could all be cached in memory - after all, they are the same for all users so why fetch and dynamically create the page for them from the database for every request? I'm sure some - or maybe / hopefully even all - of the suggestions above are actually employed here. If not, they could greatly improve on the performance and reliability of the site. Since the source code for the site isn't open (as far as I know), there's not a lot anyone other than the admin can do, however. Although your suggestions would surely help, they're rather advanced and not the easiest to implement. Remember that Mozillazine admins have other jobs, too, so time is not endless. I think your suggestions would be pretty large changes in architecture so don't expect anything. Of course you may be glad if I prove wrong :) I think the SQL errors ain't that bad. It normally takes just one reload here and there to get something displayed > It normally takes just one reload here and there to get something displayed So why not automate the reloading by providing an HTTP refresh timer? "So why not automate the reloading by providing an HTTP refresh timer?" Why not fix the problem instead of providing a workaround? The fix, at it's crudest is quite simple! Pseudocode: Change this: DatabaseConnection *con = getDatabaseConnection(); // use the connection here into this: DatabaseConnection *con; while ((con = getDatabaseConnection()) == NULL) { wait(100); } // use the connection here That's all it would take, at the crudest. Add a retry counter to stop trying after x amount of tries. It's not rocket science! SQL errors are often caused by too many open connections to the database that hold too many locks. If you have a CGI waiting to send data down the wire, and it holds open connections, other newly-started CGIs won't be able to open connections and will throw up error pages. In computer science terms: We have uninterruptible hold-and-wait of mutual exclusion resources (i.e. DB connections). One little circular wait condition will deadlock this whole site. Temporary solution: while(no DB connections available) { sleep(1); } I'm a little confused (about your post, not about SQL). Your subject line seems to indicate that you think that the SQL errors are bandwidth releated, but the content of your post seems to indicate that you do understand that the problem is not bandwidth related. Which is it? An increase in bandwidth would have no affect on the number of open connections (ok hypothetically there are scenarios where lack of bandwidth could interfere with opening new connections, but it is extremely unlikely that this is the case here). So I still stand by my previous statement. #60 Provided an easy solution weeks ago - still thereby stylo Wednesday February 20th, 2002 10:47 PM I see we've gone back to tables. Shame. As I suggested weeks ago, just go to http://glish.com/css/ or http://www.bluerobot.com/web/layouts/ and get a two column layout stylesheet. done. This site is so simple it doesn't need tables, and it certainly doesn't need a css table layout mode. (I also posted the basic layout needed in the bugs forum.) I really don't understand what the fuss is all about. I'd be glad to whip up the stylesheet for the site if needed. #61 Re: Provided an easy solution weeks ago - still thby kerz Thursday February 21st, 2002 12:00 AM It doesn't work, and we've decided to give up on CSS for the site for now. The footer will float to the top if you abs:pos the sidebar div or the content div. jason Here is today's page in css. http://scootrs.com/moz/ Please check if this meets your needs. If I can help more and have time I would love to; email me via my site. #75 Re: mozillazine in CSS at http://scootrs.com/moz/by theuiguy Thursday February 21st, 2002 1:43 PM Looks great to me and also works relatively nicely (degrades well) in Netscape 4.x. #76 Re: mozillazine in CSS at http://scootrs.com/moz/by strauss Thursday February 21st, 2002 1:43 PM Looks fine to me in IE5.1 Mac. I\'ve seen too many complaints about mozillazine layout, and AFAIK you are the first that is doing something about. Good work stylo!!! #116 Re: mozillazine in CSS at http://scootrs.com/moz/by sacolcor Monday February 25th, 2002 8:47 AM Nicely done! Kerz, do you think you'll have the time to take a look and see if you can adopt these techniques? I notice it's using XHTML Transitional, which probably allows it to degrade a little more cleanly than HTML strict. I tried xhtml strict but got complaints about the inputs with inline elements from the validator. Didn't bother to figure it out. The degrading, though, is due to the css using @import, no? Also it needs to be checked in ie6 to see if the ie conditional css for it is needed or not. I excluded ie6 assuming it knows what it's doing. But I haven't heard a word since posting it, so I'll go back to not helping for now. Was fun anyway. Was even complimented on http://glish.com stylo~ I use the Mozilla stylesheet and it looks great. Occasionally the stylesheet doesn\'t load properly, but a reload always fixes it. Simply changing the Mozilla Style to the preferred (\"stylesheet\") and IE Style to the alternat (\"alternate stylesheet\") instead of the other way around might fix the problem. N/T __ Your account has been disabled talk to Asa on IRC or email (bugzilla.mozillazine.org) Posted on N E T S C A P E 6.2.1 and no, I don't spell it like Mozilla I've said this once before on this site and I'll keep saying it, even if mozilla isn't 1.0 the site should still be made so that it at least renders properly in it. It's not that hard, every site I've done looks the same in IE 4 NS4 and Mozilla all using one stylesheet javascript and html4. I think their quest to make it slim is overshadowing the bigger issue of advocating mozilla as a viable browser. Would you use a brower who doesn't render the main advocacy site of that browser correctly? Am i the only one who hasn\'t encountered this bug? I run NS6.2 and Moz0.9.8 in two different environments at home and work and have yet to see this bug you keep screaming about even though im in and out of Moz\'zine a couple times a day every day. Do i need to be on the dailies to see it? Is there some trick? Are there only 4 people on the planet who experience it? Am i the only one who hasn\'t encountered this bug? I run NS6.2 and Moz0.9.8 in two different environments at home and work and have yet to see this bug you keep screaming about even though im in and out of Moz\'zine a couple times a day every day. Do i need to be on the dailies to see it? Is there some trick? Are there only 4 people on the planet who experience it? Speaking of bugs... how about the dual submission above. I entered my response... entered my login id and password and hit submit. Oops.. moz-zine tells me i typed my password wrong, because i forgot which password i use for this, so i enter the other one that i think it might be. That one works. But wait, i get back the listing and ive sent two submissions. Does this mean that the first attempt submitted even though i entered the wrong password? Looks that way to me. Speaking of bugs... how about the dual submission above. I entered my response... entered my login id and password and hit submit. Oops.. moz-zine tells me i typed my password wrong, because i forgot which password i use for this, so i enter the other one that i think it might be. That one works. But wait, i get back the listing and ive sent two submissions. Does this mean that the first attempt submitted even though i entered the wrong password? Looks that way to me. Woops again... this time i know i only hit submit once. So how come i got two submissions? and more inportant that that... why did i only get one this time? looks like a bug in 0.9.8. I hate having to research to see if a bug report already exists cause i never find one. then i file one for the bug only to find out there was already 3 reports for it that i didn't find. It really is okay to enter a duplicate bug (as long you never duplicate yourself :-). While everyone would rather duplicates never happened, it is better for the quality of Mozilla to have two reports than none at all. Yes, you are encouraged to do a little research before opening a bug, but don't feel guilty about it, as long as you enter all the required information. "Bad" bug reports that don't have important information like the Mozilla build information will be severely dealt with. Ypou know what I often encounter bugs listed in very inexact wyas. For example if I am wanting to find if the bug for a page display error has already been reported, how likely am I to find the bug report when the reporter reports it as "The page is horked". No wonder some bugs have duplicates. Reporters might consider being as exact as their technical knowledge allows, for example "Type flows over graphics and is incorrect" is less likely to get a duplicate bug submitted than a bug reported as "This page is horked." Just an observation. The real question should be, why can't a multi billion dollar global corp throw a little money at the #1 site that promotes it's browser? Actually, why can't the same corp throw some money at it's browser and get the friggin thing out the door? The real question should be, why can't a multi billion dollar global corp throw a little money at the #1 site that promotes it's browser? Actually, why can't the same corp throw some money at it's browser and get the friggin thing out the door? So does this mean that 0.9.9 will be the last milestone before 1.0 (i.e. there won't be a 0.9.10)? Alex Read the roadmap. :) This should be the last one... I know that 0.9.9 was always intended to be The Last Milestone Before 1.0, I just wanted to know if it's now been decided that it will be. Alex Yes, and they are working hard at retargeting bugs, and tree setup to accomplish that goal. As 1.0 was supposed to be an api freeze but there is still a lot more that wants to go into mozilla they came up with the idea of seperate branches. 1.0.x branch will be api frozen, while still being worked on to fix bugs and possibly add features that don't mess with the interface. While work will continue on further 1.x releases, which may alter the api. This way third party developers can have a target and be able to know that improvements will still be made in the browser they are targetting, without worrying about api changes. http://www.mozilla.org/roadmap/mozilla-1.0.html says "various APIs" won't change until 2.0. Do you know which APIs are frozen for all of 1.x and which are only frozen on the 1.0.x branch? Yes, infact mozilla is so commited to 1.0, that they are remarking many bugs to 1.0.1 and beyond. In the knowledge that we need the 1.0 freeze before we can get to where we really want to be. can't wait to see it. :) How about some FreeBSD binaries of 0.9.8 before 0.9.9 ? As soon as someone with a FreeBSD box builds them.... There are no such boxes owned by mozilla.org itself. You willing to do it? (And yes, I'm serious). But it has since disappeared. BTW, it isn't all that difficult to build Moz from the ports tree. Who is the "they" you're talking about? Tinderboxen are contributed by a broad range of people. If the person contributing a FreeBSD tinderbox has stopped providing that service then someone else will need to step up and champion that platform or it will go unchampioned. If the person providing the FreeBSD builds has stopped providing that service then someone else will need to step up and champion that platform or it will go unchampioned. --Asa I don't get it - there are FreeBSD nightlies - mustn't there then be a FreeBSD tinderbox? One has nothing to do with the other when it comes to any builds besides the official mac, windows and linux builds. Just because someone contributes builds doesn't mean (s)he contributes a tinderbox. A tinderbox has to be available fulltime, making builds as often as it can spit them out. mozilla.org doesn't make FreeBSD builds nor does it contribute a tinderbox for FreeBSD. This is a purely voluntary contribution by someone willing to make daily builds (if they are daily). --Asa We're accepting contributions. --Asa I\'d love to build a BSD binary package for mozilla..... Although the reason I want binaries is because mozilla takes hours to build from source, I would still love to give something back to the project... Great! If you can contribute a daily build regularly that is currently not being built regularly please email me, asa@mozilla.org, or Dawn Endico, endico@mozilla.org. --Asa #179 I glad we\'re getting close--when will NS catch up?by MozSaysAloha Wednesday March 6th, 2002 7:51 AM I am *very* glad we are getting close to 0.9.9 and 1.0.0. I can\\\'t wait to see the fruits. In the mist of my glee, I ask myself: when will Netscape catch up? If my memory is correct, Netscape 6.2.1 is based on 0.9.4.1. As we all know, there\\\'s been a boatload of improvements since then. Netscape has sat in dry dock... http://ftp.mozilla.org/pub/mozilla/nightly/2002-02-20-16-trunk/mozilla-i386-unknown-freebsd4.4.tar.gz Has anyone here actually seen it? I\'ve been waiting for this a long time! Really, this (along with better performance yet) is one thing that I really hope to see in Mozilla 1.0. Anybody know how far we are to be able to use Mozilla whilst developing web-pages with POST form http://bugzilla.mozilla.org/show_bug.cgi?id=40867 Please, stop whining about this bug! I know this sucks, but I cannot see this complaint pop up again and again and again. If you want it so much, go and code it yourself. If people didn't whine, we'd still be sitting in a field stacking mud for some overlord. Anyways, I agree this bug should be fixed by 1.0, not to mention http://bugzilla.mozilla.org/show_bug.cgi?id=55583 These bugs make mozilla look foolish and I believe the browser will not be taken seriously by the development community until they are resolved. Everybody knows about this bug. Nobody likes it. But whining about it doesn't fix it. People are working on it, but it's a hard bug. non-rhetorical question: Why is this bug hard? The server sends HTML to the browser and the browser renders it. Why can't Mozilla just hang onto the HTML and show it? read the bug it depends on, http://bugzilla.mozilla.org/show_bug.cgi?id=40867 There's huge discussion there. The reason it is hard is because every proposed solution has drawbacks that various people refuse to accept. So the people writing the code have to figure out the "best" solution that will fix the most issues while creating the fewest new issues. If you think you know the perfect solution, please let everyone else know so that we can get it fixed. However, before you start, you should read through all the proposals presented so far and all the responses to those proposals. Your idea may have already been discussed. <p>I just read through the entire thread. Wow. It seems to me there are two issues: 1) on certain sites it's dangerous to relaod the page (ie. when shopping), 2) developers working on dynamic pages need to be able to see the source behind the _current_window_. The first problem can be addressed with a warning "viewing the source of this page will.... The second can be addressed with a preference ("keep the source to the current page around, even if it slows things down and takes up 10 times as much ram").</p> <p>In any case, this bug needs to be solved, even if the solution isn't optimal. If the solution is really that bad then make it an option. For people like me who develop dynamic web sites this bug is critical.</p> I cannot see why Mozilla "will not be taken seriously by the development community". The view-source oddities have been around all along (and have been there for previous Netscape releases < 4.x). Still I was using Netscape for testing because it had such nifties as syntax highlighting and a meaningful page/frame info. Now we have not only a JS console, but a DOM inspector and a JS debugger (though I donÄt knwo how to use the latter - any help file somewhere?). And the new page info, which should be in 0.9.9 will be great. So there is plenty of stuff for the developing community. But I have to agree that the mentioned bug is a pain for the devolper and it is a pity that one has to switch to IE (or perhaps Opera, etc?) in some situations. http://www.mozilla.org/projects/venkman/venkman-walkthrough.html First think you must know for Venkman: files are loaded through its Tasks->Navigator command. I spent some hour of frustration before undestanding that other already opened browser windows cannot be debugged. "I cannot see why Mozilla 'will not be taken seriously by the development community'." Let me see if I can help you out here, sparky. Clue 1: "Wow. I'm really hyped about this new uberbrowser. Lemme just shut everything down so it will run acceptably." Clue 2: "Funny, this works in every OTHER CSS/JS/whatever-capable browser I've tested it in." Clue 3: "I remember this preferences dialog. I saw it back in 1998. Oh well, guess I'll edit my preferences by hand again. Where was that file..?" Clue 4: "Huh? Why does my page look like crap?" (There was a bug a while back, or several bugs, or something, that caused Mozilla to choke on my CSS and ignore most of it.. something which it didn't do back in the days of 0.9.6 or thereabouts. It was around for, as far as I could tell from trying nightlies, weeks. For all I know it may still be around.) Clue 5: "Gee, now it won't even run at all." (NuBus Mac installer crashes.) I'm only one web developer (and a mere hobbyist at that) and my experiences are anecdotal, but please, explain to me why I should take Mozilla seriously, if you can. I used to be a Mozilla supporter. I was caught up in the promise and the anti-MS sentiment. But now I see Mozilla for the sham it is: people pretend it's the greatest browser ever made, but then if any complaints are leveled against it, its supporters and developers are quick to scream "it's pre-release software!" and "if you want it, code it yourself!" Gods help Mozilla when it hits Version 1. The wolves will tear it to shreds. #163 Re: Re: Re: Re: Re: View-source still not fixed :(by asim Wednesday February 27th, 2002 9:15 PM <<Clue 1: "Wow. I'm really hyped about this new uberbrowser. Lemme just shut everything down so it will run acceptably.">> Yes, Moz is big on the memory side. My work box has a nightly build in the 20-30 Meg rage now, as opposed to IE 5.5's 10-15 Megs. No argurment there. <<Clue 2: "Funny, this works in every OTHER CSS/JS/whatever-capable browser I've tested it in.">> Perhaps they were using code that's IE-specific? If not, perhaps it's a bug. Given that Moz's CSS-compliance is generally rated as the best, neck and neck with Opera depending on the test, I'm wary of any pages that don't work. On my home Linux system, pages that don't work usually turn out to be IE-specific, and don't work on anything here (Mozilla, Opera 5 or 6, or Konqueror, although Konqueror sometimes makes it through) <<Clue 3: "I remember this preferences dialog. I saw it back in 1998.>> How much has the interface for, say, IE changed? Who even remembers what version of IE was out 3 years ago? I'm unaware of why such a build of Mozilla should be seen as something to base current pratices on. <<Clue 4: "Huh? Why does my page look like crap?">> I'l agree that some of the decisions on how to render pages are...odd. And I wish there was more docs on how to fix a legacy page for Mozilla. But, you know, it's possible that I can simply sit down, take the time out, and write the docs myself. <<Clue 5: "Gee, now it won't even run at all.">> I've toasted IE installs in the not-too-distant past. Moz still needs lots and lots of help, but it's coming along. Also: Mozilla!=Netscape. I've heard pleasant things about the more recent Netscape releases, and I think it's a mistake to assume the whole project is down the tubes because the announced-as-beta-or-alpha-cutting-edge software doesn't work. Perhaps this means one should use less cutting edge tools, such as a Milestone build or the latest in the Netscape 6.x series. Now, as far as "please, explain to me why I should take Mozilla seriously, if you can.": Frankly, it's one of the two best browsers if you want to code to standards. That's enough for me right there, as a Web Designer. My goal, when I code, is to construct a web interface that people can use. Coding a site that works well in Mozilla is a strong indication that it'll work in every other browser out there, even text-based ones. The same cannot be said, always, of IE, esp. if you code using FrontPage. "Gods help Mozilla when it hits Version 1. The wolves will tear it to shreds." Ah, yes, of course. Oh, wolves? Shread away!: "CNET's decision: It's a tie! Who'd have thought? After adjudicating five rounds of convincing arguments, we ended up with a hung jury. True, Netscape won the popular vote hands down. But our traditional voting process demands that we call it a tie. (Fortunately, we didn't allow any room for a third-party browser, such as Opera, to snatch votes away from either contestant.)" From http://www.cnet.com/software/0-3227883-8-7614087-1.html?tag=st.sw.3227883.bhed.3227883-8-7614087-1 . Keep in mind, that's IE 6 vs. Netscape 6.1. Netscape is up to 6.2 now. ----Woodrow "Perhaps they were using code that's IE-specific? If not, perhaps it's a bug." Entirely possible, on both counts, but nevertheless frustrating. "How much has the interface for, say, IE changed? Who even remembers what version of IE was out 3 years ago?" Mozilla's prefs dialog seems rather woefully inadequate to me. Maybe this is simply IMO, but it seems to me that some sort of expansion and reorganization is in order to address Mozilla's strengths and options rather than Netscape 4's. I'm not sure what that has to do with IE at all, unless you mean to argue that Mozilla is "good enough" as-is because IE isn't substantially better (and there are those who would argue that point as well). "I'l agree that some of the decisions on how to render pages are...odd. And I wish there was more docs on how to fix a legacy page for Mozilla." This has nothing to do with the point I was trying to make; did you bother to read my parenthetical explanation? Mozilla's CSS *broke*. It suffered a major loss of functionality that did not exist in earlier versions of the software. I would like to know how in the bloody hell anyone is supposed to develop web pages for a browser that ignores 90% of their style information.. and the fact that Mozilla is supposed to have industry-leading CSS support makes this even more of a farce. Even if you say this is a temporary (or fixed!) bug, I can attest to the fact that it lasted for weeks. This is not acceptable to a web developer, unless he can afford to simply wait around while the coders get Moz working again. "I've toasted IE installs in the not-too-distant past. Moz still needs lots and lots of help, but it's coming along." I think you've missed my point. I am talking about a piece of software that DOES NOT WORK. In fact, let me reiterate that just to sledgehammer the point home (though doubtless someone will misread it anyway): MOZILLA DOESN'T WORK. MOZILLA DOESN'T WORK. MOZILLA DOESN'T WORK. At least, not on my machine. This is a known bug (apparently) which, again, has gone weeks without repair as far as I can tell. If you can build and test pages with a browser that's incapable of running whatsoever, then please allow me to congratulate you on your ascention to godhood. Meanwhile, for mere mortal men, not being able to run Mozilla at all makes it peculiarly unsuitable for development. I'd love to code to standards, as would any sane developer. I'd like to know how Mozilla allows me to do that, though, when (a) it doesn't run at all, and (b) it would fuck over all my CSS even if it did. For all it's faults, and there are many, at least IE will render pages for me. May I politely suggest that you tone down the inflammatory language? Chanting in all caps does not raise the level of debate. Yes, the bugs in Mozilla, as well as the missing features, are very distressing to anyone doing DHTML or CSS development. There's a moving target problem, as well as a high density of annoying little issues that have to be worked around. One reason I talk so much about the bug problem is that as a JavaScript developer who tries to push the envelope in terms of what is possible, I see a ot of bugs that an ordinary end user wouldn't. I'm used to a situation in Netscape 4.x where I literally would have to spend three quarters of my time working around Netscape bugs. When I see a cavalier attitude towards an ever-escalating defect curve in Mozilla it makes me think I'm in for more of the same on the new project. (I also can't help noticing the irony that open source has been touted as a way of making less buggy software when in fact it seems that open source projects can't even begin to bring basic bug tracking under control, though major commercial developers have done so for many years.) I don't think that shouting is going to make anyone pay more attention to these issues, though. I feel your frustration but you should look at the pragmatic consequences of your style. First, thank you for your suggestion to Ugg. I don't mind disagreement, but I do mind that sort of stuff just a little. Along the lines of more civil disagreement: <<When I see a cavalier attitude towards an ever-escalating defect curve in Mozilla it makes me think I'm in for more of the same on the new project.>> This line leads me to a question, strauss. Forgive me if you've addressed it elsewhere, and just point me there. I've read your commentary of the bug tracking in Mozilla for some time, certaintly through this thread. And it strikes me that you and Asa seem to be talking about 2 different ways of looking at the data. Now, of course, there are "lies, damn lies, and statistics", so anything anyone says can and will be suspect. Yet, I've seen Asa say, in the thread, on 2 occasions I can recall, essentially "You're looking at the Bugzilla data in a way that's far off than what we see in the team. Talk to me, and I'll be happy to explain our view in detail." And, I guess I'm wondering why you've not taken him up on that offer. It seems to me -- and maybe I'm missing vast parts of the picture here -- that, when I have a dispute with someone over rather complex issues, it's useful to understand their side, if only so that I can better shape my discussion. Sorry to butt in. And thanks for reading. ----Woodrow I agree with you as a matter of policy. I think you're new here -- forgive me if I'm wrong -- so you might not have seen that I've tried to have that discussion more than once. If you look upthread you'll see how reasonable disagreement with that party has always come out when I've tried. The results have been remarkably, and unfortunately, predictable. After numerous rounds of explosions I tend to be less than enthusiastic about conversations with the person. <<Mozilla's prefs dialog seems rather woefully inadequate to me.[...]but it seems to me that some sort of expansion and reorganization is in order to address Mozilla's strengths and options rather than Netscape 4's.>> Well, what would you like to see? <<did you bother to read my parenthetical explanation? Mozilla's CSS *broke*.>> Yes, I did. I addressed the issue in my response to your next Clue: "Perhaps this means one should use less cutting edge tools, such as a Milestone build or the latest in the Netscape 6.x series." As bad as NS 6.0 was, there's a point here -- it's labeled as production code, ready for the masses. Moz isn't. If you want stability, at least take the time to use the code that's labeled "production-ready". If you still find the bug, I'm ready to jump-start the wolves. I did when NS 6.0 came out. <<If you can build and test pages with a browser that's incapable of running whatsoever, then please allow me to congratulate you on your ascention to godhood.>> Y'know, I've never said Mozilla is the greatest browser ever. Not once. I use it, but it's one in a set of tools. It runs for me, right now. It's run for me on a number of different boxes & OS, and I'm not a killer C programmer. Has it failed? Oh, heck yes. But, obviously, it runs for a lot of people. And I'm sorry that it doesn't run for you. It does not automatically make Mozilla a crap product, no more than my inability to install Morpheus on my Win2K box makes it a crap product. And there are those who can fix that, potentially. I trust you've been in contact with them? ----Woodrow There is a handy workaround here: http://bugzilla.mozilla.org/show_bug.cgi?id=55583#c209 You could add it to your personal toolbar for quick access. It doesn't have syntax highlight though. + The site looks fine in IE5 Mac now. And Reply links point to the right messages in flat mode. Actually the site looks just like it did before the recent "improvements." I'd thank somebody for the bug fix, but given that I was insulted just for pointing out the problems, I think I'll pass. Don't you so thoroughly enjoy being insulted for pointing out flaws, it's a lovely feeling. Or my favorite, getting chastized by Asa for complaining about a free product. Yum! I have never seen anyone in these forums get insulted for pointing out problems. I have seen people get criticized for HOW they point out problems; for example : whining that no one from Mozillazine.org or mozilla.org is doing enough stuff fast enough. falsely accusing developers of intentionally ignoring "the most important bug" ignorantly insulting developers by saying that their code is sloppy or that a bug is easy to fix repeatedly bitching about a known problem as if their annoying rants somehow help get the bug resolved constantly complaining that a bug has no patch yet when they themselves have never supplied a single patch for any bug There are more reasons why people have been criticized in these forums, but I think variations of the above cover the most prevalent ones. If you are offended or insulted when someone criticizes you for one of these things then stop doing it and people will stop criticizing. The vast majority of the people posting here are able to discuss bugs without ever getting criticized; if you are one of the minority who cannot, then perhaps you should think about what you are doing differently than everyone else (hint: it probably has to do with your attitude). Someone fixed one of the problems that you have been whining about, but you do not think you should thank them because someone else "insulted" you by pointing out how rude and obnoxious you are? Do you realize that that only reinforces the criticism that you are unreasonable and ungrateful? Just downloaded 2002022003 and the win32 fullscreen mode is excellent. Congrats to the devs for a superb piece of functionality. Print preview also kicks ass. WP Long loyal fan of Netscape - using 6.2.1 and check the Mozillazine forums daily. I thought that with Mozilla 0.9.4 that pop up windows were dismissed with the following sentence in the preferenced file - user_pref("dom.disable_open_during_load", true); Seemed to work fine for many months with no pop up windows - since last Saturday they are poping up again Any assistance? Thanks - Harvey Try creating a file called user.js in the same directory as prefs.js, and putting that pref on the third line of the file. (The second two lines or so aren't read for security reasons I believe.) user.js is like prefs.js, but the values are unchangable. Basically, once you set them in there, they can't be changed by anything else, and if they are, they'll revert back to the value in user.js when the browser is restarted. jason nt Hi, I'm using 2002022103, but with other recent builds I've been having this problem as well...Mozilla seems to be having trouble reading themes, including the ones it comes with. With Modern, the scrollbar is half-there, the Navigation Toolbar kind of looks like it's still loading, and the sidebar half-works. I would give a screenshot, but I kinda need a server... I'm on Windows 98, with an RAGE LT PRO AGP 2X from ATI. This has not been a problem in the past. Any help would be appreciated. You'll see at dummyaddy@email.com (password is 12345678) I posted a shot of how horrid this chrome looks (go to Sent folder if it's not in the Inbox). To add to this stuff, Moz isn't registred in Add/Remove Programs. I would report this as a bug, but it would be kinda hrad don't ya think? Good think I'm reformatting... Also, I know this isn't a profile problem becasue I just took mine apart and reinstalled restarted, etc. Anyone who dual-boots or feels that dual-booting should be a real option for Moz users should vote for bug 12911, at http://bugzilla.mozilla.org/show_bug.cgi?id=12911 because a fix for this bug would allow full sharing of preferences, mail data, search engine choice, etc across platforms. This bug prevents anyone who dual-boots from accessing their mail or setting a default search engine on both platforms they boot to- the preferences are stored in a way that makes that data platform-specific, because absolute filenames are used. Please help get this bug acted on. Let your voice be heard! #85 Re: Attention- help get a vital bug acted on ASAPby strauss Thursday February 21st, 2002 9:35 PM Potentially destabilizing bug that affects about one eighth of one percent of the potential market (assuming about half of Linux desktop users dual-boot). Not a good thing this late in the game. nt #93 No arguments - just attacking the poster, as usualby macpeep Friday February 22nd, 2002 9:01 AM n/t The originator of this thread tried to help for Mozilla's success, in his own way. How Mr. Strauss responded to that? With the usual dose of sarcasm and, once again, his typically out of context attitude. It's exactly like if you visit a motorcycle forum in order to post about how dangerous and unconvenient is to drive a motorcycle, instead of a car. Did you get my point now? Oh no, I suppose you didn't. So, keep defending useless and annoying comments. Keep playing the devil's advocate and post (here and on slashdot.com) more articles about the complete dominance of IE in the browser market and the freedom of speech (only for defending those who laugh at the work of others). Once I thought you were interested in more creative things: filing and triaging bugs, creating testcases, helping others to use and efficiently test Mozilla. But if it makes you feel better, go with Strauss. I want bother with you anymore. Maybe you are the same person, after all. Please guys, that's not as much a case of trolling as you think it is. BOTH sides have excellent points. Yes, it's incredibly annoying and counter-productive for someone with multiple OS's to have multiple profiles, and it would be a great feature (I personally think it would be an excellent addition and should be implemented), plus it could be expanded to be multi-'puter capable etc., but on the same token, do you think this is something that's needed for 1.0 or soon thereafter? The vast majority of end-users do not double-boot, nor would they want to. We're at 0.9.9 and messing around with fundamentals should really be halted until well after we make a solid Mozilla 1 and maybe 1.1. I really don't think that this is a priority right now. And no, I don't dual-boot. "With the usual dose of sarcasm and, once again, his typically out of context attitude." That's not how I read it. I checked out the bug report and found that it was, just like Strauss said, a bug that is an "annoyance" rather than a "show stopper" and on top of this, is only a bug for a VERY small minority. We're now just one milestone away from 1.0. At this point, it really is unwise (in the sense that it's risky) to do any changes and/or added features. At least that's one point of view and I for one share it. If you read up about software development processes, you'll see that so does a lot of other people. I don't know what Strauss' ultimate motivation is for reading about Mozilla and following the development. I believe it's the same as mine tho. I've a long time Netscape browser fan that at one point witnessed that Microsoft's IE had FAR surpassed it (for whatever reasons, legal or not) in quality. Then, along comes Mozilla, which looks extremely promising. Only from where we're looking at things, it seems like the project is in a chaos. Slipping deadlines, serious problems with bugs etc. You probably disagree with it, but that's how I (and I'm pretty sure Strauss too) looks at it. If you search other forums, you'll find that a lot of people (if not the majority in fact) agrees with us. As far as "playing the devil's advocate" goes (on Slashdot and here), I post in response to comment that I think are wrong, and I post my views when I thik I have something worth something to say. In the latest case, which I guess you were refering to (on Slashdot), i posted in reponse to someone who was basically, indirectly, suggesting Mozilla has a market share of 17% and that Mozilla was in 2nd place. My reponse was that it's not true - out of those 17%, the vast majority is Netscape 4.x. My post was modded as follows: Moderation Totals: Insightful=1, Interesting=1, Informative=1, Total=3 (Score 5: Informative). Like you can see, not everyone shares YOUR view that we're "just trolling". These are just different views on a subject and it's much better to discuss things than just attack the writer. Strauss has a lot of very good points and I wish I could lay out my thoughts as coherently as he does. Now he may be right or he may be wrong, but that's a separate issue. I do not personally see this whole "It's his attitude" thing that you say. Maybe you're just being a little over sensitive to comments that aren't praising Mozilla? Think about it... It's bizarre what sets people off here. What I said in full was "Potentially destabilizing bug that affects about one eighth of one percent of the potential market (assuming about half of Linux desktop users dual-boot). Not a good thing this late in the game." It's objective and straightforward, with no hint of sarcasm or insult. This somehow touched off yet another wave of personal attacks against me. maybe it's because you do have some right points but often hide them behind "Mozilla is crap and world would do better without it" comments so people don't expect anything different from you even if you make just a valid comment and nothing else. I think you're true that till 1.0 only showstoppers should be fixed (even if I'm one of your eigth of one percent...) and this is the way Mozilla goes if you look at the roadmap. \"maybe it\'s because you do have some right points but often hide them behind \"Mozilla is crap and world would do better without it\"\" Could you URL me to a post by Strauss that says something like that? I knew someone would ask...would be nice if there were a search for comments. But I'm sure someone can remember strauss' postings, saying that he would be better off without Mozilla because it's just one more browser to test his applications on and that it's JavaScript is weak cause of lacking drag&drop support and the like. I'm sure you understand that postings like this don't leave a nice picture when done on a Mozilla advocating site. E.g. from my perspective life would be much easier without IE and it's layout bugs. "I'm sure someone can remember strauss' postings, saying that he would be better off without Mozilla because it's just one more browser to test his applications on and that it's JavaScript is weak cause of lacking drag&drop support and the like." Wait now, let's not change your story. What you claimed he said was: "Mozilla is crap and world would do better without it" What you said above is totally different. Plus I'm sure there was a context. Not just "Mozilla sucks" in a stand-alone post at root level in the threat. So come on, let's not throw wild claims around. Give us the URL to the post(s). You even said he does it OFTEN. If that's the case, it shouldn't be hard to find. After all, Strauss posts here a lot! To be fair, it's not possible to search for messages here, and hasn't been for quite a while. I'm not sure why, since old messages are still archived. There was a search feature here long ago. I don't think I've ever said "Mozilla is crap" or "Mozilla sucks." What I have said and will continue to say is that its ever-escalating defect curve is a matter for great concern, and that it calls into question the basic tenet of open source, that "to many eyes all bugs are shallow." The project is now postponing hundreds of important bug fixes because they seem to be under an external pressure from Netscape to call something 1.0. They've compromised on their quality, performance, API freeze, and standards support goals, and they will be releasing as 1.0 a browser that crashes every three and a half hours. It's not a quality product. Some people may not want to hear this, but it's not something I'm making up. I think you covered most of the bases in explaining your own attitude: "I'm a long time Netscape browser fan that at one point witnessed that Microsoft's IE had FAR surpassed it (for whatever reasons, legal or not) in quality. Then, along comes Mozilla, which looks extremely promising. Only from where we're looking at things, it seems like the project is in a chaos. Slipping deadlines, serious problems with bugs etc. You probably disagree with it, but that's how I (and I'm pretty sure Strauss too) looks at it. If you search other forums, you'll find that a lot of people (if not the majority in fact) agrees with us." That's not some bizarre, mean-spirited perspective expressed for purposes of evil -- it's a realistic and disappointed look at the failed promises of the Mozilla project. http://ftp.mozilla.org/pub/data/crash-data/ I'll try to make it real simple for you. Assume 4 users test a nightly build. They all use the builds for 6 hours or less (it's a nightly build and that seems a reasonable guess about how long they'll browse with it before getting the next nightly build). Four of them use builds that don't have talkback, they opt out of talkback in the install routine, or they decide to hit the "NO" button when talkback offers to send in the crash report. Two of them use builds that are talkback enabled and are willing to submit incidents if they arise so they're the only ones we can really talk about . One of the testers with a talkback build crashes once at startup and again a few hours later in the 6 hours he uses the build and he opts to click "OK" on the talkback reports that are generated, sending them in to our servers. The other person running the talkback build never crashes in the 6 hours of use so no talkback agent comes up and she has no talkback report to send in so we have no data on her 6 hours of uptime without a crash. Now, what would talkback data tell us. It would tell us that we had an MTBF of 3 hours. Is that an accurate representation of the experience of our 4 users? No. Is it even an accurate representation of the two users that enabled talkback in their builds? No, it's not. So what do we do about this, you ask (or should have)? It's pretty simple. We have Milestone releases where people use the builds for more than a day. See, if you replace your build you get a new talkback agent and no data from your previous build is ever sent in and calculated. This is why t's important that we get people using the browser for long periods of time since many people don't crash for long periods of time. So with a Milestone, in the first few days we get a lot of reports from the early crashers but no reports from the people that haven't yet crashed. Given enough time most of the testers will find a crash but it takes several weeks before we start seeing incidents from enough of the sample to generate meaningful MTBF stats. We gotta wait for all those people who don't get crashes in the first few hundred hours of browsing so we can average them in too. It simply wouldn't be fair to exclude the people with exceptional uptime unless you were willing to exclude the people with exceptional failure rates. So to look at a daily MTBF number is to look at a small piece of the story which doesn't count the many testers that don't crash in the first day (and we know there are plenty based on the numbers of milestone talkback incidents where the first crash doesn't occurr till well after a day's worth of uptime). You're only seeing the people who did manage to crash before they updated their build. I'll bet that many here will attest to replacing a nightly build without having crashed it. I do this all the time and even your misunderstanding of talkback data and your misinformation in this forum only gives me a slight itch to to intentionally crash my browser right before I update to a new build just get my 14hours of crash-free browsing logged in the system. But I don't and there's no reason to play with the data like that just to spite a couple of people that don't know what they're talking about. Daily talkback data is useful for identifying the begin and enddate of a new crash signature in the nightly builds. It helps us to predict some of the topcrash bugs that become more apparent when we have hundreds of thousands of talkback incidents for a single build rather than hundreds. Daily MTBF is so close to useless that it's not even worth analyzing. We don't have talkback in the daily builds for calculating MTBF. We have it for identifying the most common stack signatures and tackling the most visible crash bugs as soon as possible. --Asa I've put far too much time into trying to explain this to you. I'm taking a break. Feel free to speak freely from ignorance for a few days while I put my time into actually working on making Mozilla better. Great. Where are the milestone MTBF numbers? You've only ever posted the link to what you are now saying are the dailies -- which you were happy enough to say were important when they were going up instead of down. Asa the only bad thing is that these nearly useless MTBF numbers correspond perfectly to my feeling about mozilla stability. MTBF > 5.5 hours, less then one crash per day; MTBF around 3.5 hours it crashes nearly every other hour under heavy load. And currently the daily builds are unstable. And if you look at 8000 talkback reports then they provide a quite good base for a statistic. There may be differences on the behaviour of single testers but I think they will be smoothed out by the large number of testers and reports. (That's hwo statistics works.) If one looks at the comments, it seems that the majority who submits these reports belong to the core testing community. So I believe the MTBF really reflects the status of the builds. Pardon me, but you are making things up - or at least deliberately misleading people based on faulty statistics and unsubstantiated statements. #1 - You give a link to the MTBF numbers that Mozilla keeps. If you take a moment to read the top of the very document you link to you will notice it states explicitly - "MTBF ... based on ... reports from testers that have crashed". Keep carefully in mind that if you never crash, then your uptime will never be recorded. This drastically skews the results and is not a true "MTBF" as normally used in industry. #2 - You state that you are concerned with the 'ever-escalating defect curve' even though it has been pointed out numerous times that just counting bugs in Bugzilla is meaningless data. #3 - You state 'The project [has] compromised on their... API freeze" and yet the APIs are being frozen as can be seen by checking LXR and Bugzilla. Yes, it is true, not every API will be frozen - only those that are known to be critical to allowing developers to produce external apps that work in the Mozilla framework. Give one specific example of an API which will not be frozen for the 1.0 release that matches the Mozilla 1.0 release criteria. You are failed to provide a 'realistic look at the failed promises' of Mozilla. The characterization of these numbers MTBF is the characterization of Netscape and Mozilla. They are not completely accurate for a few reasons, such as non-Talkback builds andbugs and crashes that are not reported. I've pointed them out a few times and you're the first person to say that not crashing means you'll never get your uptime reported. Where do you get that assertion from? When I've tested milestone builds I've found that I crashed just about as often as they said. As for the Bugzilla defect curves, I've pointed out many times that the most reliable number is the Reopened line, a standard quality bellwether, and one that consists only of reviewed bugs. The Reopned line is quite disturbing: http://bugzilla.mozilla.org/reports.cgi?product=-All-&output=show_chart&datasets=REOPENED%3A&links=1&banner=1 . The inability to use some of the other lines is also quite disturbing, much like flying a plane without instruments. Total API freeze was the stated goal. That has been reduced to a key API freeze. Similarly for standards conformance. These represent major retreats from the 1.0 release criteria. With Strauss completely this time. Outside preesure is quite apparent, and this kind of pressure is not good for an open-source project. The frequency of normal-tagged bugs at near-0.9.9 status is frightening. In my case, crashing is up from 0.9.7. Don't get me wrong; Mozilla kicks @$$, and open-source does too, however more time should be spent on stability, less on new features this late in the game. New features can wait. I stated where I got the information from. It came directly from the crash data you linked to http://ftp.mozilla.org/pub/data/crash-data/detailed-crash-analysis-all.html [Warning that link is a 14.7MB document]. It states explicitly "MTBF [is] based on ... reports ... from testers that have crashed". If you don't crash, then your uptime numbers do not end up in the MTBF calculations. That's a big extrapolation from a little piece of casual boilerplate. It doesn't sound like you have any more knowledge of the detailed process than I do. In any case, since Netscape and Mozilla both call these MTBF numbers, I am comfortable treating them as MTBF numbers -- albeit ones with large error bars -- until some actual evidence to the contrary is submitted. It was not just extrapolation. To quote the Mozilla FAQ http://www.mozilla.org/docs/mozilla-faq.html : "Talkback-enabled builds help the community by letting Mozilla.org members where in the code crashes occur." To quote Asa: "[Mozilla will send reports] only when you crash and only if you click OK to send the report". The evidence would be in the source code to Mozilla http://lxr.mozilla.org/ . Strauss, did you think about this at all before posting? "Mean Time Between Failures" by definition requires that the browser fails. Whenever anyone runs their web browser without ever crashing, there is no MTBF and so obviously their uptime is not figured in. There should be no reason why Mozilla.org or Asa or fuzzygorilla or anyone should have to explain this to you. There is no reason why they should have to provide any evidence to prove to you that rants about MTBF have no basis in reality.
""Mean Time Between Failures" by definition requires that the browser fails. Whenever nyone runs their web browser without ever crashing, there is no MTBF and so obviously their uptime is not figured in." Why doesn't the counter keep counting the next time you start the browser then? And then when the first crash occurs, it sends over the cumulative uptime until that crash had occured. The only thing that would be missing in that case is the times when people installed a NEW browser, used it for a short time until they AGAIN got a new browser and did not crash in between. I doubt those people are so many that it would be a big factor in the statistics.. Maybe I'm wrong.. Naturally, MTBF does not require that there be a failure, for the reasons you've cited. What's more important to me at least is (1) the daily MTBF numbers have suffered a sharp decline, in the vicinity of twenty-five per cent, and (2) we're being told that there are better milestone numbers which we have not yet seen. I wonder where we can find those numbers. I've asked Asa but he traditionally refuses to answer questions I ask of that sort. Less important but still relevant is the fact that MTBF was trotted out in the past to show that things were constantly improving, and are now being dismissed as completely irrelevant now that they are dropping. This says a lot about the quality of information coming out of the project, but it does not in itself convey information about the project. How can you have a "Mean Time Between Failures" without ever having a failure? By definition, a MTBF calculation REQUIRES a failure. In the case of Mozilla that failure must be a crash and the user needs to have a Talkback build and they need to agree to let TalkBack send the data to Mozilla. MTBF 'Mean Time Between Failures' is typically based on a measure of failures during the total run time of all units. If a unit does not fail, then its run time should still be included in the total run time in order to get an accurate MTBF value. The value calculated by the talkback builds does not include those of us who do not experience failures. Thus it is not what the industry would call an MTBF. Example: Because I only use milestones and view a limited number of web sites, I have not had a crash while viewing the web since 0.9.3. My usage is not included in the talkback MTBF calculation but should be for a 'true' MTBF calculation. My current copy of Mozilla 0.9.8 has been running since Feb 13 - 2 weeks of up time. The Talkback agent does keep counting the browser runtime between starts and stops. It takes a failure, however, before _any_ data is sent to the talkback server. " The only thing that would be missing in that case is the times when people installed a NEW browser, used it for a short time until they AGAIN got a new browser and did not crash in between. I doubt those people are so many that it would be a big factor in the statistics.. Maybe I'm wrong.." You are. You're very wrong. "The _only think that would be missing_?" That would read better if it said, "The more common case that is missing". You can doubt all you want about Mozilla nightly downloads but that fact is that the overwhelming majority of people downloading the nightly builds are doing just that _downloading_ _nightly_ builds_. They don'y use those builds for months on end, they don't all use them exclusively. They do use those builds for a day's worth of browsing (or less) and then they get the next nightly build. Talkback does not measure uptime across different builds and a significant percentage of users do not crash in between the two builds. I, for example, am about to get my Tuesday morning build and I haven't crashed Monday's build (at least 14 hours of use). I'm not alone in this. This is born out by looking at the percentage of people who send in thier first talkback report with many days usage before a crash in Milestone builds. You can feel free to doubt all you want and you can talk, like strauss, as if you knew something on the subject but there are much more knowledgeable people (dozens of them) that know what this data means, and how to get the most value out of it. All the speculation in the world here at mozillazine doesn't make the browser any better. If you actually want to do something to help improve Mozilla's uptime then let me know and I'll be glad to help get you started. If you're not actually going to do something useful then I've already wasted too much time explaining things you. --Asa #154 Re: Re: Re: Re: MTBF (was Re: Re: Re: Re: doh)by SubtleRebel Tuesday February 26th, 2002 4:12 PM I have not experienced a Mozilla crash yet this year and I use it everyday. Most of the time it is open 24 hours a day. So I have a lot of uptime that is not being counted. Note that I have only been downloading builds that Asa says are stable. #157 Re: Re: Re: Re: Re: MTBF (was Re: Re: Re: Re: doh)by PsychoCS Tuesday February 26th, 2002 5:39 PM That is AMAZING! However the *vast* majority of users, especially testers, will crash quite frequently. I think that MTBF is quite accurate. Most of us, as others already said, download nightlies for everyday usage, the lifetime of a nightly in our boxes isn't more than one or two days. We accept the "risk" involved (no real risk because it's always a good practice to keep backup of critical data). The most unstable period (from what I derive from my personal experience and the new bugs filed everyday) is in the first days after branching a milestone and in special cases where a large part of the code is being rewritten. I for one had 2 browser crashes during this month, using Mozilla at home and work. I filed two bugs, one is assigned and the other one was a duplicate (fixed now). I also had crashes with IE this month (which, btw, I use very rarerly, that is its MTBF is extremely low for me:)). Assertions like "Mozilla crashes every 3.5 hours" or "crash quite frequently" are based either on misinterpretation of statistics or a bad individual user experience. The fact that some nightlies are essentially unusable because of a big crasher doesn't prove the above statements. These statements also don't include the fact that on some platforms Mozilla might be more stable than in others. Finally, quoting from the home page of www.mozilla.org, about the nightlies: "Created most weekdays from the previous day's work, these will probably work, but maybe not". As a user, indeed I am worried about the recent extended period of regressions (reached into the freeze stage). I made my own conclusions but I don't play the manager nor I continuously cry out into the public about problems I refuse to offer some useful hint or data. Oops... this was intended for someone else in the thread. I do quite a lot of testing with security, trying to add certificate, delete certificate, view signed messages, and I crash very, very often (with recent nighlies, but it happened also earlier). My personnal MTBF is no more than a few hours, and when I try to get some of these things working it can go down to a few minutes. Thta's a very interesting datum. I suspect that different people have different usage patterns, and that for some patterns Mozilla actually has gotten quite stable -- like for instance, single-window browsing of non-secure sites without plugins or JavaScript. In other cases, like people like me who tend to have twenty windows open, or people like you who work out the security features, crashes are much more common. The fact that for some people Mozilla actually is very stable may explain why they tend to think we're making up our concerns, while we tend to think they're downplaying the significance of the problems. I do use Mozilla with many open tabs and windows and MailNews and still have no crashes even on pages with plugins and JavaScript. But I'm sure there are many people who use certain parts of the browser that aren't as stable or browse on sites where Mozilla just has a problem. This is a very complex software so different using behaviour can lead to extremely different results. That's exactly what I wanted to explain, strauss. Trying to understand why opinions are different may lead to far better discussions. If everyone would do that many flames would simply not appear... btw. I think there is an additional reason why MTBF numbers are so low for Mozilla: not only that much uptime is simply not counted. Nightlies are for testing Mozilla and when testing crasher bugs you send many talkback reports with uptime of maybe not even a minute. But that's not be normal using of the software. > Have you reported that bug in Bugzilla? Bug Id? I will, but it takes time to do a good bug report, especially since quite a few problem with S/MIME messages I have come from profile corruption. If the stable release no more has this profile corruption, then they're not so important. But if the stable release corrupts the profile as often as recent nightlies ... So I'd need to create a clean profile, import certificates inside it, check if it gets corrupted after a while, or not, and then it's really worth reporting. Also I'd need to check all problem reports until now, to see what is already reported, what is new. I was talking about the browser part and I don't use certificates. Have you reported that bug in Bugzilla? Bug Id? Other than that, I do use a lot of open windows, visit sites with plugins and javascript. Admittedly, that kind of sites are more capable of crashing Mozilla but I am also pleased by the fact that crashing bugs are treated as an issue of very high priority. Indeed people do not have the same habbits when browsing, this explains the different experiences being reported. Btw, this is the best comment I read from Mr. Strauss for months. If you, him and others could dedicate some free time in reporting / triaging crasher bugs instead of simply complaining, Mozilla would even better, regarding to stability. You already do that? Ok, again retracting my words... #130 Bugzilla defect curves (was Re: Re: Re: Re: doh)by fuzzygorilla Monday February 25th, 2002 5:46 PM Whether you are looking at "New", "Open", or "Repened" bugs, the arguments remain the same. #1 - You are looking at 'all' products. Bugzilla tracks a lot more than Mozilla. Bugzilla also tracks Bugzilla, Calendar, Grendel, Tech Evangelism, and others. For example look at Bug 70249 http://bugzilla.mozilla.org/show_bug.cgi?id=70249 which is about making Mozilla.org a non-profit Organization. #2 - Just because it is "Reopened" does not mean there is no duplicates. In fact they are probably more likely, because they are less likely to be re-triaged to find duplicates. #3 - Bugs are often "Reopened" because people [erroneously] don't wait for the build with the fix, or for tracking purposes [ Bug 109353 http://bugzilla.mozilla.org/show_bug.cgi?id=109353 or Bug 73535 http://bugzilla.mozilla.org/show_bug.cgi?id=73535 ] or because the person who opened the bug for a new feature disagreed with the developers who marked the bug WONTFIX [ Bug 21445 http://bugzilla.mozilla.org/show_bug.cgi?id=21445 ] or because the bug was accidentally closed prematurely [ Bug 58041 http://bugzilla.mozilla.org/show_bug.cgi?id=58041 ]. All of the above reasons will grow with time. And Bugzilla goes back a long way. Basically, without actually checking *why* a bug was reopened the argument is moot. Saying that it is a 'bellwether' is true only after you properly select and categorize the problems. Else it is GIGO - garbage in, garbage out. #132 Re: Bugzilla defect curves (was Re: Re: Re: Re: doby strauss Monday February 25th, 2002 6:16 PM I did make a mistake and forget to select "Browser" instead of "All" for product, which I usually do when looking at these stats. Here's the corrected link. As you can see the shape is virtually identical. http://bugzilla.mozilla.org/reports.cgi?product=Browser&output=show_chart&datasets=REOPENED%3A&links=1&banner=1 Your reasoning that the Reopened line is even more likely to contain duplicates escapes me. More examined and more active bugs are obviously less likely to be duplicates than less examined and less active bugs. Reopened bugs are primarily those that were marked as fixed and which have been reopened because they either weren't fixed or became unfixerd (regressed). I acknowledge you have found examples of bugs of other types that are marked as Reopened but I don't think that changes the usual meaning of the status. And again, I'm not impressed with any argument that says the bug numbers are junk and should be ignored. That in itself would be an even more serious problem than upwards defect trends. It would mean quality is out of control. Personally, though, I do not think the bug numbers are anywhere near as inaccurate as some here would like to think, particularly the Reopened line, since all the bugs there are guaranteed to have received scrutiny. It would be good if there were more powerful charting tools in Bugzilla, though. #134 Re: Re: Bugzilla defect curves (was Re: Re: Re: Reby fuzzygorilla Monday February 25th, 2002 7:10 PM The reasoning for higher duplication goes like this: Most of the triage eyeballs are on "unconfirmed" and "new" bugs. Once a bug has been moved beyond that point, they belong to individual developers and thus duplicates are less likely to be noticed. Many eyes do make short work but only when they are focused in the area. Bug numbers are only junk when you try to use them without any investigation. The fact that bugs are "reopened" does not mean they regressed. Having a bug marked "WORKSFORME" and then "REOPENED" may simply mean that the problem report was poorly written in the first place or that the problem was reported as being all when it was really platform specific or just that the problem is intermittent http://bugzilla.mozilla.org/show_bug.cgi?id=126282 http://bugzilla.mozilla.org/show_bug.cgi?id=109950 . Having a bug marked "DUPLICATE" and the "REOPENED" may simply be a mistake or because of a decision to split a bug up into pieces http://bugzilla.mozilla.org/show_bug.cgi?id=63137 Having a bug marked "FIXED" and then "REOPENED" may just be due to a bug in the operating environment outside the measure of Mozilla http://bugzilla.mozilla.org/show_bug.cgi?id=32443 #136 Re: Re: Re: Bugzilla defect curves (was Re: Re: Reby strauss Monday February 25th, 2002 9:56 PM With respect to the issue that only bad news gets reported, you've pretty much convinced me. I would note that there are also factors working in the other direction: lack of Talkback on Mac, crashes that are so severe they disable Talkback, and people opting out of Talkback reports. It's hard to say which is a stronger force, but as I said, the last time I tried using a milestone for a day, it crashed almost exactly on schedule, after about four hours. It's also surely worth nothing that the so-called MTBF rating has been going down rather than up over the last few months. Mozilla fans were happy to take credit when it was creeping up last fall, but now that it's creeping back down, it seems that's not of any real significance. You can't have it both ways. Good dials good, bad dials irrelevant? I don't agree on the higher duplicates issue with Reopened bugs. Seems to me you're not basing that on any analysis. It would also seem very strange if key players weren't taking a close look at Reopened bugs, since those are the ones that (from a root-cause analysis perspective) are most likely to point out basic stability problems. Anyway, the argument that's been made that the New and Unassigned defect curves don't count has been that no one was looking at them -- if that's true, then the Reopened bugs do at least have someone looking at them, and so ought to be more accurate. I agree that there are different kinds of Reopened. As I said, it would be good if there were better charting facilities in Bugzilla. More powerful query inputs to the charts would produce better data. You haven't done anything to establish that the majority of Reopened bugs aren't regressions, though, only that some aren't. Looking at the chart, I see a correlation with milestones that received relatively better or worse public reception on quality grounds. Does it seem to you like it's just a coincidence that all the metrics established to mark progress on the project are negative? Can systemic errors account for the situation actually being rosy but there being not a single quantitative indicator that points in that direction? That's seems pretty dang weird to me. The large software projects that I've shipped were all highly dependent on QA metrics to find their way out of the forest of problems that is product release. All the indicators seem to show the plane is flying into a mountain, but don't worry, it's just all the dials that are wrong? I have a hard time buying that. I do agree that the dials are wrong, though. #140 Who gives a #$%^ about the number of bugs? MTBF?by zevious Monday February 25th, 2002 10:35 PM I don't really care that much about any of that. I have been using the nightly Mozilla builds for close to a year. I started out just using the browser to see how it worked. It was pretty buggy, etc. As time has gone on, I have fully moved from NS4.7x to Mozilla. Many new features have been added in this time, sometimes causing some regression, but those problems are usually gone in the next build. At this point, I rarely crash. If I do, I simply reload and continue on. How often does IE crash? I just don't understand why you put SO much signifigance on bug counts and other charts. You sound like the dude at Mozillaquest. What is the point. Is it just for the sake of arguement? Don't you have ANYthing better to do? Try spending your time USING the browser and reporting bugs instead of dwelling on the previously reported bugs, your life and ours will be a better place. 90% of the posts on here are responses to your nonesense. It's just a waste of time . We all now know that you could do this better and how you feel it should be done. BUT, if you could do a project such as this better, you would be. You're not. All we here is lotsa noise about how you have done this or that, but NO specifics to back up your claims. Those that can do things, do. Those that can't, talk about doing it. (I keep telling myself that I'm not going to be sucked in by this crap anymore and here I go again.. maybe this will be my last rant? :) ) The bug chart shows something like a little above 400 reopened bugs while a Bugzilla query for the keyword regression by which all regressed bugs should be marked finds 308 bugs (all done on browser only). From this you could think that real regression rate should be within about 30% of the line that Bugzilla chart shows. Of course this is based only on a quick search and only true for this point in time. But the 30% may tell that the regressionrate could even be sinking while the chart rises (which it doesn't even do at the moment). You are true in one point: more, and more accurate data would be good and may help driving the project in the right direction. Please point to a Mozilla document that promises a "Total API freeze". The promise has always been that the _public_ APIs would be frozen. That remains a goal of the Mozilla 1.0 release. You would be correct to say that the promise has been further qualified to mean that all frozen public APIs will not change in the 1.0 branch http://www.mozilla.org/roadmap/mozilla-1.0.html . Thus there *may* be some public interfaces that are not frozen and thus *may* change in the 1.0 branch (but they also might never change). But we are still not at Mozilla 1.0 so I would wait before claiming that the project retreated from their release criteria. "The project is now postponing hundreds of important bug fixes because they seem to be under an external pressure from Netscape to call something 1.0." You couldn't be farther from the truth. Netscape management could really care less about what we call the next 10 milestones. They haven't let our version numbers stand in the way of their mozilla-based products. Neither has OEOne. Neither has Rovia. Neither has Galeon. Neither has Tuxia. Neither has Beonex, or IBM, or Bloomberg. All these companies and many more are shipping products based on Mozilla and none of them have let our version numbers stand in the way of their releases. "and they will be releasing as 1.0 a browser that crashes every three and a half hours." You simply don't know what you're talking about. A little data is clearly a dangerous thing. With the complete lack of understanding of talkback methodology you're out on a limb making claims that are simply foolish. If you'd like to know how talkback works and what the data means then feel free to ask but don't spout off in here like you know what your talking about when it comes to talkback data because you just don't have a clue. If we've failed you so, then go away. You've got nothing to gain by hanging around and we could all save some time and make mozilla that much better if we were'nt responding to your clearly moot criticism (if you don't expect us to be a success then why offer even constructive criticism). Go find some other project to set your hopes on. >If we've failed you so, then go away. You've got nothing to gain by hanging around and we could all save some time and make mozilla that much better if we were'nt responding to your clearly moot criticism (if you don't expect us to be a success then why offer even constructive criticism). Go find some other project to set your hopes on. Could you realize how miserable a life of a troll would be if there wasn't a work of someone else to taunt? He comes again and again, saying that Mozilla has bad project management, that any open source projects would fail etc. I did agree with him once that, in *my* point of view, there is a human resource problem in Mozilla. But, since I could not offer anything useful in that field, I shut up and turned in other fields where I think I could help. Coming up and (essentially) saying (amonsgt other things) over again that Mozilla is going nowhere, is trollism. If you strongly believe there's truly a problem that should be fixed asap, say it loudly but only once. Then, offer your experience and intelligence for something more useful than bitching in an advocacy site. This was an exaggeration for better showing what I mean. Maybe the words were too hard, maybe just a lack of experience with this foreign language. What I wanted to say is that he sometimes has a good point but burries it in comments which may seem just insultive to people around here and so may not be heard. I'm just suggesting that he should try to be somehow more diplomatic and try to understand the arguments that everyone tells him. I think they are like his own not always wrong... > What I wanted to say is that he sometimes has a good point but burries it in comments which may seem just insultive to people around here and so may not be heard. < My perspective is that I work hard to make sure there is nothing resembling a personal attack in my messages, while those who disagree with me seem to go out of their way to be as overtly insulting as possible. YMMV, but when I'm accused of being insulting for saying, e.g., that dual-boot users represent something like one eighth of one percent of the desktop market, or for saying that talkback has become so difficult to use due to CSS problems that I won't use it any more, then I know that my supposed "insults" are the products of someone's imagination. #104 Re: arguments on such a rude post? Are you kiddingby bzbarsky Saturday February 23rd, 2002 3:10 PM The post was not at all rude. All it said is that the bug in question is probably not 1.0 material since it will take lots of work, be potentially destabilizing, and lead to little reward (lots of reward for a few, no reward for the many == little reward). This is not to say the bug should not be fixed or it's not an annoyance. It's just not in the class of bugs that should be the focus in the next few weeks, unless the profile back end people have absolutely nothing else to do. Please read the 1.0 manifesto for more information. "one eighth of one percent of the potential market (assuming about half of Linux desktop users dual-boot)" If this is not sarcasm, ok, I retract my words. Cultural differences, perhaps. I failed to realize that he is so willing to help Mozilla's success, as usual :-) (time for me to be sarcastic). I'm sure the same person will upset you, sometime in the foreseeable future, as he did with many others. As regarding to myself, not a single problem left: I won't bother again. There are far more interesting things in this life than arguing with Strauss-like people. Excuse my intrusion on the arguments- please read the bug before you make a lot of remarks concerning the bug. Moz developers have, as a whole, agreed that using resource urls in preference files is feasible to implement with little effort, is necessary for more than just dual-booting (see the bugs which depend upon it), and is the way of the future. The bug had an odd argument in its comments because a couple of people didn't understand the nature of the bug (comments about 52 to 62), but the rest of the commentary is informative. This is not just a dual-booting bug. It was first posted by a moz developer who wasn't dual-booting but was concerned about the tendency of his prefs to be stored in an absolute instead of relative way, which is contrary to design ideals. Only considerably later was it made a point that this would enable dual-booting profiles. The bug is not, as far as I understand, "potentially destabilizing"- please see bug comments 11-14. Comment 28 was the first to address dual-booting- over two years after the bug was opened. This bug is, when its dependent (and really dupe, in my opinion) bug 58647 is included, is definitely a mostfreq- which suggests that a much larger portion of Moz users than .125% are concerned about this bug. Thank you in any case for pointing out to me, albeit in an indirect way, that I need to include more information about this bug in any later attempts to help draw attention to this bug. "[The bug submitter was] concerned about the tendency of his prefs to be stored in an absolute instead of relative way, which is contrary to design ideals." A good point, that this concerns many more users, but I still think that this is something that can easily live with getting a LATER tag. It would be nice to organize everything, but Mozilla really does work well right now, and 1.0 doesn't necessarily need this. Yes, this MUST be addressed, but Mozilla doesn't end at 1... And guys, face it; Strauss presents a good point too. Or rather maybe it's a bug at MZine or my build of some sort. My title defaults to "Help with Chrome!!" instead of Re:. And it caught me twice. Does this kind of thing happen with you guys when you post? No default title on my responses, I think- not even a Re:. BTW, a design inconsistency may be a non-1.0 issue, but an easy-fix mostfreq is a 1.0 issue. Variations on this bug (with the two dependent bugs it would pretty much fix automatically which I have no idea why they have a separate existence) have been submitted roughly 25 times- if 1.0 has a considerably higher user base, which is the hoped-for situation, this bug will cause a triaging disaster. But, of course, you're more than entitled to disagree- the main goal in spreading any information, if you're not just a propagandist, is not to get everyone to agree but to get as many people as possible to become aware. In any case, I would have to disagree with your last comment's title :) Actually, it may be as simple as password manager remembering the title field--it's only supposed to remember login/password, but I could see how it might screw up here--I'll check it out...even if this isn't a bug, it's kinda funny how many Mozilla bugs are found right here at MZine. Oh, didn't know that it actually was a mostfreq. Sounds like it's more popular than logic would dictate, however I don't think that it'd be an easy fix to make different versions, for example, use mostly the same files (e.g. make Linux not have to use appreg), but a synchronize feature akin to Netscape Mail could work as a temporary thing between profiles, maybe... What the heck. Just throwing weird ideas around. What I'm concerned about is that resources are focusing too much on stuff that isn't crucial before 1.0., and on stuff that could lead to the inception of more bugs. When Mozilla is released publicly, it must be on time, and it can't just be better than the rest. It's gotta be a 'killa app'. Netscape 6 tarnished Mozilla's reputation, so now, we must take back the internet (mwahaha). I don't care if Mozilla is on time. If all new features were stopped during one month, and all significant crashing bugs (this include profile corruption bugs that later lead to a crash) corrected, that would be great. Mozilla has enough feature, a rock-hard crash resistant Mozilla 1.0 that is what would really be a great thing. Unfortunately, we kind of have commitments to developers, end-users, and companies (which, by releasing 1.0 we will demonstrate--see the 1.0 'festo) that can't be ignored, and Mozilla already is quite 'rock-hard'. Mozilla is an ongoing process that can't just be 'done' at 1. Actually, I'm just playing devil's advocate. I pretty much agree with what you're saying. :) I work for a large company that has a mixed Windows/Unix environment, and I have my home directory shared so it can be accessed by both. It would be very useful if I could keep the same profile for both Windows and Unix. Hard-coding platform-specific entities is not good, and I'm glad this is being investigated. #153 Re: Attention- help get a vital bug acted on ASAPby johnlar Tuesday February 26th, 2002 3:13 PM I'd like to make a note, anyone dual-booting I'm sure can handle a nightly, so an experimental branch totally seperate from the direction to 1.0 would be a good idea. This bug is slated for a .9.9 fix. While the developers working on it don't quite have the fix finished (and thus won't make it for .9.9 unless a miracle occurs), they do have a very good implementation. This is not a bug which endangers the state of the tree or anything like that. In addition, it's not just a dual-booting bug- it's a design inconsistency and a mostfreq, both things Moz.org wants to get out of its system before 1.0. Putting this on an exerimental branch would be self-defeating as the developers are probably going to be putting these changes onto the trunk before 1.0. It really helps to look at the comments by the developers on the bug before making a comment such as the one you just made. What happens to bugs that were introduced after the last Netscape release? I am referring to: http://bugzilla.mozilla.org/show_bug.cgi?id=120940 http://bugzilla.mozilla.org/show_bug.cgi?id=123140 Will they be fixed by Netscape in their release or will the be fixed by Mozilla before that? Waiting for Mozilla 0.99 when will gtk widgets be included in the default builds? anyone know if this will be included? http://www.jpeg2000info.com/ |