Update on 0.9.4Friday September 7th, 2001We asked Asa for a quick status on 0.9.4's status, which was for release this weekend, and here's what he had to say: Haven't really done any serious testing on this.. but occasionally when exiting Mozilla (when used in turbo mode) via right clicking on the systray icon it causes Mozilla to crash. Usually was after installing an xpi. crash unloading turbo is http://bugzilla.mozilla.org/show_bug.cgi?id=97620 and we won't enable it by defualt unless we can get this fixed. --Asa I must say that I am pleased and impressed with the progress made in the last few weeks. The -turbo option was really needed. On my system, Mozilla now loads faster than IE most of the time. I am also very happy that (finally) non-Latin web pages are rendered reasonably well. Although some works still needs to be done, Arabic pages are completely readable. Mozilla is certainly becoming more stable with every passing day. I have been a critic of overzealous optimism in the past, but I believe that Mozilla is finally close to its 1.0 release. The end of the 1.0 development marathon marks the beginning of another marathon, that of user-acceptance and enhancements. I believe that Mozilla is well positioned for it. Good job for the developer of this amazing product. Actually, Mozilla has been pretty good at displaying non-Latin LTR languages on Windows and Linux for a while. But I'm glad to hear that the RTL languages are coming up to speed. A problem I encountered with mozilla.exe -turbo was that installing a plug-in with it running isn't a good idea. It has to be restarted for the plug-in to be recognised. Hopefully there can be a way to work around this. type about:plugins at the location and it should work afterwards javascript must be enabled to do so. The most loathsome bug in recent mozilla history - windows stealing focus from each other (http://bugzilla.mozilla.org/show_bug.cgi?id=77675) - is rearing its ugly head again (http://bugzilla.mozilla.org/show_bug.cgi?id=97067). This severely impairs the browsing experience. 0.9.4 should not be released with this bug since no milestone should feel worse than its predecessor. There is a stop-gap patch available which should be applied if no better solution can be found in a short timeframe. The original bug 77675 had over 200 votes and around 50 duplicates. 0.9.3 fixed this to everyones great relief. Let us not go through this again. People, please go vote for this bug (http://bugzilla.mozilla.org/showvotes.cgi?voteon=97067) and express your feelings on the matter. Please please please please people do vote for this bug, but do not comment on it with stuff like "please fix this" or "it's annoying". Let the developers fix it now, they know it's serious, and unless you know how to fix it, commenting on the bug won't help. Thanks for keeping the noise down to a strict necessary. -Fabian. I was trying to make people vote for this bug and raise the attention of those not running the latest nightlies and therefore experiencing the situation first hand. I think I was doing valid advocacy to push a very real and severe bug into the limelight. If we are to use the less than perfect patch available we need to voice our opinions on the matter. I cannot see why posting a very fuzzy bugreport should be okay and raising awareness on a well known issue should not. BTW the number of votes on the bug is increasing by the minute.. Sorry Fabian I do not see the error in my ways. Just consider that if the bug get's spammed with a lot of "yeah, fix this" comments that the people actually working on the bug are going to start ignoring the comments and might miss something important. Bug comments should not contain advocacy and "me too" statements because they make it harder for the developers and QA to actually read throught the bug and work toward a fix. Trust me. Vote for the bug but do not fill it with a bunch of "please fix this" and "this is the worst bug" comments. If you do then you risk driving away the people that would otherwise be fixing it. --Asa OK, acknowledged. I will try to keep myself to nominations and votes in the bugreports. But mozillazine is a forum for advocacy isn't it? Where else should I say "This annoys me, vote for it if you feel the same." ? Votin is fine. Please do encourage people to vote for bugs. Please do not encourage advocacy and "me too" comments. Thanks. --Asa #18 Re: Re: Re: Re: Re: window focus stealing has regrby baffoni Saturday September 8th, 2001 5:40 PM Don, I think they are saying that you should say "Express your feelings _by_ voting", not "Vote _and_ express your feelings" which implies that people fill up the comments fields with stuff like "this is annoying", etc., when the vote is sufficient. This is definately a forum to point out such high-visibility issues. #43 Re: Re: Re: Re: Re: window focus stealing has regrby ogiesen Monday September 10th, 2001 1:50 AM AFAICS noone ever objected to you raising this topic here. They only made an additional comment to your call, which they felt (out of experience) was missing. The point being: THIS is definitely the right place to express feelings about bugs, the Comment field of Bugzilla however is not. Oliver I'm sorry I chose your comment to make my comment ;-) I was talking in a very general case. Definitely expressing your opinion on this forum is a very good thing, but I was tryig to avoid what happens in all the bugs like that one, i.e. useless "me too" comments. I certainly wasn't talking to you, rather to everybody. Sorry if you took it personally, I'll try to be more careful in the future. -Fabian. No offense taken, Fabian. You and Asa made me see the light ;) My initial comment indeed appears to incite people to post "me toos" into the bugreport when I really just wanted to make them vote for it. I will be more careful with my wording the next time around. BTW, the bug went from 9 to 74 votes in less than 2 days, so I suppose I was quite successful :-) This time with working links - sorry. The most loathsome bug in recent mozilla history - windows stealing focus from each other http://bugzilla.mozilla.org/show_bug.cgi?id=77675 - is rearing its ugly head again http://bugzilla.mozilla.org/show_bug.cgi?id=97067. This severely impairs the browsing experience. 0.9.4 should not be released with this bug since no milestone should feel worse than its predecessor. There is a stop-gap patch available which should be applied if no better solution can be found in a short timeframe. The original bug 77675 had over 200 votes and around 50 duplicates. 0.9.3 fixed this to everyones great relief. Let us not go through this again. People, please go vote for this bug http://bugzilla.mozilla.org/showvotes.cgi?voteon=97067 and express your feelings on the matter. >>People, please go vote for this bug and express your feelings on the matter. Please do vote for the bug. Do not "express your feelings" in the bug. If you do you risk alienating the people working on the bug who don't appreciate getting email every time someone wants to say "me too". Bugzilla is not the place to "express your feelings". If you have something technical to add to the bug then plase do. If you don't have anything that will actually contribute to a fix then please do not comment. If you care about a bug getting fixed then remember that Bugzilla is a bug database and people are actually trying to do work there. Your advocacy and "me too" comments do nothing but disrupt that work. Use Bugzilla votes not comments. --Asa Oh, I'm sorry this is very ambiguous. I meant to say express your feelings *by voting* for this bug. Go vote! Asa, do you think people saying things like "me too" in bug comment because they didn't realise how Bugzilla works? They might not realise that developers (and anyone in the cc-list) will get an email when a comment is added. A Bugzilla tutorial would be great, I'm still exploring how to make sure whether a bug has been filed. beebebebebe > A Bugzilla tutorial would be great, We'd love it if you wrote one. Send it to me when you are done :-) Gerv gerv@mozilla.org But there is already a Bugzilla (actually a "how to report a bug") tutorial and it's written by you. If there is really a need for another Bugzilla tutorial (based on the average reporter's point of view and focused on general Bugzilla "attitude"), I could write one for you. I have filed enough duplicates and noisy comments, so I might know (maybe) a few things about how to avoid them now :) But I think your guideline is sufficient for a bug reporter. It's our habits that prevent us from writing good bug reports. One of these habits is not to read your guidelines :) Hopefully I will learn some day to post correct links. This is the bug I was talking about: http://bugzilla.mozilla.org/show_bug.cgi?id=97067 Go vote for it! Any news about when (or even if) we might get -turbo support on other platforms? I'd certainly like to have a command to execute when I log into Gnome that will get Mozilla ready to rock quickly when I click its icon... If you are using Galeon (which uses Mozilla), it has an -s option that acts the same as -turbo. Macs don't exactly have a -turbo mode, but if you have Virtual Memory turned on (as everyone should), Mozilla (or any app) will launch much more quickly after the first time you launch it. The first time you launch it, some of the code gets cached somehow, making subsequent launches much faster. Brian! Does MacOS come with a turbo-style option built in? (it leaves a program in memory until it is specifically quit). If so, then there would be no point adding it to mac, but point in adding it to linux etc. Does anyone know if "-turbo" has been implemented for Linux? I haven't booted in my Linux HD lately but I'm sure this feature would be appreciated on Linux too. If not, is there a bug filled for this that I can vote for? http://bugzilla.mozilla.org/show_bug.cgi?id=86977 I think -turbo for UNIX should actually be a daemon that doesn't do much, with its main purpose being to keep the DSOs constantly in memory, so the next normal run of mozilla will use the pre-loaded DSO's and hence start up several seconds quicker. The daemon would just do the following: 1. Fork into the background. 2. Dynamically load all the DSO's that are needed. 3. Sit in a loop, alternatively sleeping and then calling a dummy routine in each DSO (that does nothing - you'd need one dummy routine per DSO) - this would force the DSOs into memory if they had been swapped out. Because no DSO's "real routines" are ever called, you won't get any memory bloat - memory usage of this daemon will be the size of the DLL's plus the main binary code. You could even theoretically have a separate binary just for the daemon, but you'd lose the benefit of sharing the image then. Another tack might be to have a truly multi-user -turbo daemon - one that can handle multiple users (maybe via fork()'ing one per user or ultimately being multi-threaded). That way all the user-independent initialisation of the daemon can be done first before it sits in a polling loop waiting for a thin-end client to contact it to start a child and then connect to that child to provide services. Not to sound ungrateful, but what's new with the -turbo option? Hasn't this been in Mozilla since 0.9? Does the -turbo switch now have a different meaning, or is just the -turbo (preloader) function significantly improved? Well various important bugs have been fixed in it, and others are on the way soon. I can't think of anything off the top of my head, but there were some serious bugs in turbo. Alex http://www.gerbilbox.com/newzilla/ One thing that has been fixed is that -turbo now works without restarting Windows. This means that: - if Mozilla crashes, quicklaunch re-activates after you restart Mozilla. - if you remove the "mozilla.exe -turbo" shortcut from your startup folder, and have quicklaunch activate the first time you run mozilla instead of when Windows starts. Enabling turbo by default before memory leak bugs http://bugzilla.mozilla.org/show_bug.cgi?id=93547 are fixed is premature. Rubbish. :-) If that were the case, we'd never enable it by default. Gerv Which is "rubbish" ? The previous post or my bug report? :-) Anyway, I agree with you. Turbo mode isn't perfect yet but it does need testing. Memory leak problems also affect the whole application but stability problems and crash recovery are of more immediate importance for turbo mode. When turbo mode was landed in the trunk, I thought it was an easy task. After a while, I realised how much complicated is to manage a resident preloading application like this. As Jesse said before, a number of interesting bugs have been fixed. For anyone who's interested in watching -turbo issues, here is the link for it's tracking bug: http://bugzilla.mozilla.org/show_bug.cgi?id=75599 I'm sorry, but I'm against the whole philosophy of the "-turbo" option. I bowed away from complaining too loudly though when it was decided to not make it the default. I could compromise with that. However, now that it has changed to being the default I must voice my strong opposition again. The whole idea is just bad. This is Mozilla doing the Wrong Thing because of influences of other companies who have brainwashed uses into thinking the Wrong Thing is "normal". Programs should not default to staying in memory even when you're not using them. If a user closes it, the program should COMPLETELY UNLOAD FROM MEMORY. If a user fully understands what they are doing, let them enable "-turbo". That's the only way it should be permitted. The desktop already has provisions for supporting keeping a window open in the background if you intend on using it again later... THAT'S the proper way of doing things. If there's something on my Task Bar, then it's running and using memory. If my Task Bar is clean, it had better the hell be unloaded. I thought part of the whole idea of Mozilla was to fix the Wrong Way of doing things that we get from other particular companies. This goes totally against that. > Programs should not default to staying in memory even when you're not > using them. 1) On which stone tablet is this written? Haven't you heard of TSR programs under DOS, and daemons under Unix? Who are you to cry that it's the Wrong Way? 2) Mozilla is turning on -turbo by default because it requires more testing, and Mozilla milestones are about testing Mozilla features. It does not necessarily mean that it will be on by default in Mozilla builds for ever. Gerv > 1) On which stone tablet is this written? Haven't you heard of TSR programs under DOS, and daemons under Unix? Who are you to cry that it's the Wrong Way? But I am using this programs. If I have a deamon running, that there is a reason for it, like cron is doing things from time to time. My personal reason against -turbo is, that it does not solve the problem of long starting time. It just hides it. And maybe programmers will not try to reduce starting time cause there is still the -turbo which is more convenient and maybe Mozilla will never get as good as it could be. So -turbo is a nice short to middle term feature but no long term solution in my personal eyes. >2) Mozilla is turning on -turbo by default because it requires more testing, and Mozilla milestones are about testing Mozilla features. It does not necessarily mean that it will be on by default in Mozilla builds for ever. If you ask me, it will. It gets more testing, thus getting stabler and better and when it's perfekt why should they turn it off? I think no one will want to lose this convenient way (at least for programmers) of getting Mozilla to start faster. > Who are you to cry that it's the Wrong Way? Or you to say that it's the Right Way? <grin> > Mozilla is turning on -turbo by default because it requires more > testing If you were serious about this (and you didn't want to give the user any choice in the matter), you would turn it on by default and not even have the option to turn it off. Which of course would cause a lot of dissent. But even by making it the default you are, to one degree, imposing your preference on other people and generating a negative reaction. If you really require testing, and don't want to alienate some community members, then say so politely and ASK people to enable this features and relay feedback. Jason. How about a brief explanation, in common userspeak, at the time of install about what turbo does. Something like: "The Turbo feature preloads parts of Mozilla at boot time. Turbo uses about 12 MB of RAM when Mozilla is not running, but allows Mozilla to launch faster after booting, and when relaunching Mozilla. This feature is similar to the default IE and MS Office installations which also include a preloading feature. Recommended only for systems with 64 MB RAM or more." I agree. While it is a useful feature, and one that many people will use, it should not be turned on by default. If testing against it is required, then notification to that effect can be stated and testers solicited during the install procedure. But it should still remain off by default. One big complaint about IE has been its tying with the OS, and the fact that it eats up memory without asking you because of this. (Even if you don't use IE, the memory it uses by, essentially, preloading itself, is still gone. This is the Big Brother method of telling people what's right for them. Granted, the Mozilla installer will offer you a choice to preload or not. Still, it should default to not exhibiting the same behaviour that Microsoft insists upon. Mozilla, I think, already loads in a respectable enough amount of time. I don't think that it's going to receive a poor reception because of its non turbo start times. But it will receive a lesser reception due to increased memory usage if turbo is on by default - and nobody realises the link between that mode and memory. If it must be enabled by default, there should be a disclaimer of sorts (as has already been mentioned) on the install screen where there is an option to disable it. Additionally, it should not ignore previous installation prferences. If a previous version of Mozilla is installed, without the turbo mode enabled, it should remain disabled during the new install. Only on a fresh install should it be on by default (if that decision remains). Jason. One vote more *against* a default turbo mode. I don't want my system cluttered with 12-20MB when I am not using mozilla. One of the criticisms of IE is that it comes loaded and intertwined with the OS. And now you want to imitate the same behavior by default? Gosh. Turbo is fine if the user has enough resources to do so and understands what effects this has, but not for John Doe and not for me as well. >Additionally, it should not ignore previous installation prferences That would be nice if it respects the existing preference. I thought about this one, since I don't use Turbo and don't like it (I've got enough RAM and speed that Mozilla starts up almost as quickly as IE, and I try to reduce my number of TSRs to the absolute minimum); but after all, your normal "I don't understand why my computer is so slow" user isn't the target end user for Mozilla: developers and your general OSD/FSF-consumer is; and those users should know what they're in for. So long as it doesn't become the default for Netscape (which is after all Netscape's decision, not Mozilla's) I guess I don't see the problem. > your normal ... user isn't the target end user for Mozilla True. But "power users" are people too. <grin> For those of us who don't use the turbo feature, and who don't like it, it's just as annoying to have it's use "pre-selected" for us. Yes, we know what's going on and we know how to turn it off. But the attittude of having it, by default, turned on for us seems, I guess - to me anyway, a little patronizing. As I mention in another post, why not leave it off by default but ask nicely if we'd be kind enough to turn it on and test it? Even though I don't use it I might be swayed to do so for the sake of some limited testing if there's a good reason to do so. But this approach is not really soliciting such voluntary cooperation. Jason. Power users like you can unselect it in the installer or better yet, don't use an installer. Use the zipped builds and you'll never even know about turbor. The feature is not enabled by default in the nightly builds (which any self-respecting regular Mozilla tester should be using anyway). I don't need your cooperation. We already have hundreds of regular nightly build testers testing this feature. What I need is the tens of thousands of occasional Milestone testers to give this a shot and see what talkback says about it when there are significant numbers of users. This is why we do Milestones! Mozilla binaries oare for testing and development purposes. If we can't use them for testing a new feature then we should stop making binaries and go back to source only. ANYONE who downloads Mozilla is a tester and is voluntarily participating in the Mozilla community testing effort. Mozilla provides binaries for no other reason. If you don't like that then lobby for the discontinuation of binaries, not the discontinuation of the using them for their only practical purpose. --Asa > I don't need your cooperation. This sounds rather ominous. I would hope that's not the attitude you want to present to the community in general. It's only *because* of community cooperation that Mozilla is the success it is. You shouldn't be so confrontational. We're all working together, giving our input. Jason. You're taking my words out of context. I don't need testing on this feature from the hundreds of people that download daily builds. We're not going to lose out greatly if you (specifically) don't want to test this. That's why it's not enabled in the nightly builds. We already have bug reports from this nightly build testers. This group is involved enough to test a feature and file meaningful bug reports. That's not what we're after with the Milestone release. Milestones go out to 100,000 plus people and those people don't file bug reports, the most we can hope for is good talkback data from a very broad range of win32 OSes and hardware configurations. These testers seldom investigate problems and file bugs. They are "shallow" testers but the sheer numbers make it extremely useful for covering issues like stability. Like I said, if you don't want to test this feature that's fine with me. You can uncheck it in the installer or use the zipped Milestone build or you can do something even more useful and use nightly builds. Milestones are always old-tech compared to the tip (usually about 10 days behind the current state of things) and the tip is where we need in depth testing. --Asa Fair enough. I guess I misinterpreted the tone of your written voice. BTW: I already do use the nightlies, so this particular default won't really affect me. Nor would unchecking the default bother me that much. I wasn't speaking for myself - I was speaking about the principle of the thing. In principle, I still disagree. <grin> Jason. Asa, As someone who has worked on software development, I can understand what you are saying in this post, and actually agree with it. Perhaps it was myself not understanding the full story behind defaulting "turbo" to on. If this is only being done temporarily for the sake of testing, then I conceed to your reasoning, agreeing full-heartedly. However, if this is instead (as I was left to gather the first time I read the news) the direction that 1.0 (final) will be, then I have to stand by my original post. Cheers... Whether you think it's the 'wrong' way or not, the fact is that it's common practice on Windows; IE, RealPlayer, and many other "frequently used" programs offer to pre-load themselves. And since memory is now dirt cheap (256 MB PC133 SDRAM for $36 on crucial.com), I see no reason why Mozilla should hamstring itself - its load time gets compared to IE in just about every review. Users who don't want to take the memory hit can always uncheck the option. Being a common practice does not imply that it is a good practice. In fact, as the practice becomes more common, it creates more problems than it solves; the performance decrease of swapping between disk and memory due to large numbers of pre-loaded large applications will outweight the benefit of pre-loading. Also, having to wait at startup for multiple applications to load, most of which you are likely not to use, doesn't make much sense. As for the cheapness of RAM: It is cheap if you order it online and you install it yourself. But, what of the person that doesn't know about Crucial, or that doesn't know that adding RAM makes the computer perform better, or doesn't have the ability to install the RAM herself, or that doesn't have $36 (and thus using Netscape 6.X instead of Opera)? These are also the people that will leave the setting at its default because they don't want to "screw things up '. Also, what about the corporate IT guys that have to walk around to 10,000 computers and add a RAM chip to each one, after they just asked their boss to but 10,000 $36 RAM chips (~$360,000 plus an extraordinary amount of labor). When an application is being used by huge numbers of people, a software solution is much cheaper than a hardware solution. For example, this IT guy can just push a new version of the application out to those 10,000 computers automatically (using something like SMS) in a few minutes. The reason I vote against this is that turbo mode discourages people from working on startup performance tuning. If mozilla is starting up in a couple seconds on the developers' machines (because of -turbo) then they won't see as much need to improve startup performance for people that don't want to use -turbo. Also, it is just a bad precedent. Imagine having IE, RealPlayer, MS Office, and Mozilla all pre-loaded and all taking ~10MB of memory when not being used. That is 40MB of memory! Now, imagine that more programs start doing this and it wouldn't be unrealistic to have 70-100MB of software "pre-loaded" on your computer in the near future. Software-image pre-loading is best implemented by operating-system, which has more knowledge of the performance details in the system. There is one ugly layout bug still around http://bugzilla.mozilla.org/show_bug.cgi?id=97619 which is breaking quite a few pages. If you want this fixed for the pending milestone, you should probably use your votes now. Nightly builds have been less than perfect for me in the last few days. We should be careful not to release this one prematurely. "We should be careful not to release this one prematurely." Statements like this seem a little silly to me. Mozilla releases builds (nightly and Milestone) for testing and development purposes. We release nightly builds several times a day, some work, some don't. No release is premature. Release early and release often works. Every nightly build and every Milestone build has problems. Some are serious and some are minor. My release criteria for Milestones is something like "release when it's better than the last Milestone" and I think that we're just about there. If you wanted to read the 16,000 or so open bugs you could find another bug of this caliber every day from now till Christmas. It has to go out the door sometime. (BTW, that bug is already on my radar. see the "critical for 0.9.4" note in the status whiteboard? that's me saying that I really want it for 0.9.4. drivers@mozilla.org aren't unaware of the bug. save your votes or use them elsewhere.) --Asa Maybe I should explain this a little more. I run nightlies almost exclusively and have been experiencing the worst builds in months (for me) over the weekend. Mozilla crashed during normal browsing which it hadn't for ages, it misrendered, it keeps stealing focus, I stumbled over a few pages that come up blank, mailnews was unusable. 0.9.3 has been working better than this (for me). So I am just doing my job - testing mozilla and giving feedback here - so that you can do your job - deciding when to release the next milestone. You are doing your job quite well, I could probably improve by sticking to mine and not try to meddle with yours. It seems that Mozillazine has been voted as the worst Mozilla news site in its own poll. I find that strangely rewarding. I believe someone flooded it because it was 2nd, just ahead of Slashdot with pretty real looking vote amounts.. Then all of a sudden, it had a couple of hundred more votes. In any case, just the fact that MozillaZine was 2nd after the obvious #1 - MozillaQuest - does send a strong message. One piece of news per month. Screenshots that are almost two years old.. A build bar that updates three times a month... so why do you bother to read the site? is it the thrill of diminishing other peoples' work that keeps you coming back? can't find a better forum to talk about how people just don't meet your expectations? no better site to post your dissatisfation with people working hard on something they believe in? --Asa Because this site is still - by far - the best site for Mozilla news, despite that it doesn't update as often as I'd like.. While there aren't that many ARTICLES here on Mozilla news, the people are quite up to date and I find that to be a better source for information on Mozilla than anything else. I get no satisfaction from seeing bad news about Mozilla, nor do I get any satisfaction from "bashing" the people working on it. I'm honestly and seriously interested in seeing Mozilla be a very successful project and I'm cheering for everyone involved. That doesn't mean that I would show a happy face when things are looking bad though. Like I've stated in the past, my wish would be that MozillaZine would report news in a completely objective way - be the news good OR bad. Right now, we get a lot of negative "news" from MozillaQuest and a number of other slightly more credible sites. The good news are mostly on MozillaZine and/or the comments here. I've found that the only way to get a real overview of the entire project is to read several sites since no one site seems to be totally credible. That's a sad situation and I believe that that's why MozillaZine was voted to be the 2nd worst Mozilla news site. IMHO, that's wrong.. MozillaZine is still the best news site, but it's far from perfect. I'm not here to bash anyone nor diminish the efforts by the people involved. Don't mistake my critisism of the product as a critisism of the efforts and/or people involved. I can't say your intentions about the project are unconcerned or even bad. But there is an evident unbalance between the positive and negative criticism of yours on the "work of the others". I would guess that you either don't have real expectations from the project or you are not aware of the displeasing effect of this kind of criticism. There's no professional (or deeply involved amateur) in any part of the world that would feel happy when his enormous, ambitious, hard work is welcomed with continuous negative comments. Developpers, testers, documentation people, managers, they all need some encouraging comments from time to time. Especially when a lot of good work has been done and they have to face the fierce competition of Microsoft. I hope I made it clear what I mean because english is not my native language. No offensive intentions, anyway. Your english is fine to me.. but then again, english is my third language (after swedish and finnish) so who knows. :) My comments are more negative than positive because I feel that the quality & schedule of the product so far doesn't warrant much better feedback. I'm a software engineer myself and I've had my share of both positive and negative public feedback. There's a difference between pointing out issues and straight out dissing people. I feel that I've only ever talked about Mozilla - not the developers. I also feel that I've always talked about specific issues, or at least provided arguments for my negative opinions, instead of attacking people. On the other hand, I've seen a couple of direct "shut up macpeep"-type of comments, which is a pretty naive way of dealing with criticism. People seem to extrapolate too much from my comments. If I say that the Mozilla UI is in a pretty sad shape quality wise, then it doesn't mean that I also think that all Mozilla engineers suck, Microsoft rules and that Mike Angelo is my hero. I've seen the same extrapolating tendencies in many comments to strauss' posts.. I wonder if people concerned about the morale effects of criticism ever wonder about the morale effects of cheerleading. In my experience, once a culture of denial and "putting a happy face on everything" sets in on a technical project, productivity goes to heck because no one believes anything they hear. and telling a bunch of volunteers that the work they're doing doesn't meet your standards sure boosts morale. Your logic confuses me. I've been involved with Mozilla for over 2 years, as a volunteer and a paid contributor and I always thought that people contribute because it feels good. I guess I should change my approach to bringing new contributors on board and start telling them how much they suck and how improving the product isn't good enough unless they can do it at a speed I'm happy with. "You didn't confirm enough bugs this week! You suck at this! When you can work harder we'll see about continuing this discussion". Yeah, I think that will work just swell. I assume you've never worked with or managed volunteers. Go use M16 ( from just over a year ago) and compare it to 0.9.3. If you think we haven't improved since then then I can see how you'd feel you have a point. If you think we have improved but just not enough then you're telling people that they're not working hard enough to meet your expectations. Telling a volunteer that they're not working hard enough for you is NOT the way to keep them motivated. --Asa It's not a matter of people not working hard enough. I think your background as a project manager must be rather limited if your only response to problems on a project is to try to get people to work harder. Structural problems need structural solutions. The first step to solving a problem is to admit and define it. Mozilla is a program in crisis. The fact that the release schedule last Fall had it shipping in January of this year, and that there is now no release schedule, proves that. The ever-increasing defect curve also proves that. The answers to problems like that are structural, not cheerleading. If you and the rest of the drivers could even admit the problem, then the powers that be could look at possible solutions, like hiring more QA staff to get the out-of-control defect curve investigated, and to do root-cause analysis of the sources of recurring defects. Or maybe it turns out that a project of this scale can't be staffed by volunteers, and can only be completed by trained and paid professionals. I'm not saying these are the solutions, only that these and other structural solutions to the project crisis don't even seem to be getting considered. You blew up at me when I simply mentioned root cause analysis a few months back. Bizarre. You and the rest of the drivers appear to be in denial, and being in denial means the problems can't be solved. You may think this has a positive morale effect, but you're wrong. The failure to solve the problems has a much bigger negative morale effect than any amount of cheerleading. People know there are big problems. They're looking to you to solve them. Strauss, even if your insane view of things were right, you have offered no real world solutions. If you have a suggestion for how to improve things then fine, tell us, but if all you can do is complain and spout theory then be quiet. Strauss, Don't take me wrong, but I think that you are being unfair on the mozilla project. I have been watching mozilla for a while, about two years from now. I think mozilla's main aim has been to "release the product when it's ready", although I was quite eager to know a release date it wasn't really there. Yes there were some vague arguments like in the third or forth quarter of 2001, but these have been speculations, the release will be determined mainly by when it's ready for 1.0 Also you have many times complained about the quality of mozilla, my opinion differing from yours there, bashing the efforts of volunteers to make mozilla better does not help improve the product. Download builds, help with duplicate bugreports, write bugreports, but just saying "mozilla is bad" will not improve the product. Nevertheless, long live mozillazine, somewhere where we can all freely express our opinions! You obviously don't understand what Mozilla is (or what it isn't). Mozilla will never "ship" unless you call binary testing releases shipping in which case we ship several times a day. We said last year and the year before that we'd call it 1.0 when it was ready. When it is ready is up to the community. When new memebers of the community start doing something new with the Mozilla architecture and expose new problems we work to correct those. This project will never be done/over. It is ongoing and will continue to get better as long as people are motivated to participate. The actual date that this project gets slapped with the label "1.0" isn't a problem. We aren't in denial about this non-problem. If it is a problem for you then I'll make a special build called StraussZilla 1.0 and you can have your 1.0 release. Netscape called it a release (twice). ActiveState called it a release (and charged money for it). RedHat and Ximian and other linux distributors called it a release (several times) and shipped it with OS updates. This "ever-increasing defect curve" you keep referring to is total bs. You simply don't have any understanding of what is happening in Bugzilla. If you stopped to see that there are more than 30,000 Bugzilla accounts (99% of which aren't professional software qa engineers) reporting many of the same issues over and over again along with requests for new features and many non-browser bugs (like UI design discussions, website spelling errors, Bugzilla keyword changes, problems with features that aren't even a part of Mozilla, etc.) then you'd have a different take on what these numbers mean. Your "defect curve" is misleading and harping on it when the product is clearly getting better, not worse, is a kind of FUD that no one needs. If you took a few months to digest the evolution of the bug system's content you'd also see that the overall severity of bugs is going down not up while the number duplicate, invalid and worksforme reports are also going up . More bugs reported doesn't mean more bugs. It means more of the existing problems are known and being digested. Generally speaking the product is not getting more bugs, we're just doing a better job at identifying the bugs we have. Your comments about "the powers that be...hiring more QA staff" expose your fundamental misunderstanding of what mozilla.org and drivers are doing. In the first place, there are many "powers that be" and most of them aren't in a position to hire anyone. We're an open source prject and take contributions from anyone wiling to give them. Some of these contributors are paid and others are volunteers but anything that finds its way into the tree is a contribution. Drivers aren't working to make a commercial-style browser release. We're working to identify a point in development when the code is ready for the many different types of code consumers (browser vendors like Netscape or Beonex, gecko embedders like Galeon or Skipstone, Mozilla platform consumers like ActiveState and OEone, etc). Mozilla code consumers like Netscape, ActiveState, Beonex and others are already shipping commercial products based on Mozilla. We could have called it 1.0 when that group was satisfied (early this year) but there are other consumers of our technology that say it's not quite ready for their particular use yet. When it is ready for everyone (that speaks up and makes requests of us) we'll call it 1.0 and probably create a long-lived stability branch for those folks to use while we work toward 1.1 and then 1.2,...2.0, 10.0 etc. If you're concerns are about some kind of commercial-style Mozilla 1.0 browser release then you misunderstand how we work. We're not under any commercial pressure to ship an app. We don't and we probably never will "ship" and app. Netscape and other vendors like Beonex, RedHat and OEone handle that part. We are solely concerned with making the technology better for our customers (Beonex, ActiveState, Netscape, Nokia, Bloomberg, all those folks using Mozilla code in their products). Because the Mozilla technology is so popular and being used in so many diverse applications and because the Mozilla community grew to encompass these varied consumers our requirements for satisfying the community have grown. We've apparently already satisfied a number of them (see the shipping products mentioned above) but we'd like to get to a better place for _all_ of them. When you are doing something significant to cotribute or distribute then let me know and I'll see what drivers@mozilla.org can do to facilitate your work (even if it means a delay in when we make a mystical, magical, tag in the tree named MOZILLA_1_0_BRANCH). I've heard all this before. It's ridiculous stuff. Have you ever shipped a piece of software or taken a software engineering class? The bug curve doesn't count? That means that you can't deal with the influx of new bugs. That means you have no quality metric. That's a huge problem. That's why you need to get more QA people, if only to sift through the bugs and get the bugs under control. In fact, though. your bug curve does count. At every milestone a certain set of bugs is identified as critical to that milestone. In every case (as pointed out by [gasp!] mangelo), you have fallen way, way short of fixing even the bugs you yourselves have identified as targets. It's not an illusory curve created by 30,000 duplicate posters -- you can't deliver on your own quality goals. I'm sorry if it comes across as a flame to point that out, but any reasonable person would agree that it indicates a problem. You have no schedule? Nonsense. In fact you do have a schedule, whether you keep track of it or not. 1.0 is the threshold for when the product becomes usable enough that it will not be rejected in the marketplace. You're not there yet. When you get there has everything to do with (1) when commercial developers like me start budgeting resources to support Mozilla-based browsers and (2) whether you have any hope of being a significant force in an IE-dominated marketplace. The release date of an acceptable-quality product, not the customer-rejected pre-releases you're boasting about, has everything to do with the future of the project, and with whether it has a future or not. Ultimately AOL will stop pouring money down a sinkhole. As for your refusal to even consider the idea that maybe the open-source development isn't working out on Mozilla, that's a religious issue, but the open source religion is dying out. Almost every company that has tried it has failed, and no company doing medium or large scale open source projects has made a profit on them. You're helping along the death of the religion -- people all over the industry are pointing to Mozilla as a cautionary tale about how open source doesn't scale to large projects. You need to ask yourself seriously whether the only way to get this thing out is to move it to a more professional footing, even if all that means is hiring another two dozen QA people to sort through the bug queue, separate the wheat from the chaff, identify the components that are causing the most problems, and find why the regression rate is so high. The volunteer QA model is just silly. Doing QA well is a job, not a hobby. No one does it for fun. You're not under any commercial pressure to ship an app? You're starting to find out just how wrong that is. But feel free to pretend otherwise right until the day all the paid developers are handed their walking papers. According to the news.com sources, Mitchell Baker was fired for exactly the kind of non-accountability you're displaying and defending. I hope that doesn't happen, but it's becoming more and more likely that it will. Since the beginning of Milestones (and i was actively testing Mozilla even before that) we have always identified a set of bugs that we'd like fixed for a particular Milestone. Developers, testing and QA community and project management all work to get bugs identified which would make this Milestone worse than the last one. We have never fixed every bug targeted or nominated for a particular Milestone. We never intend to. Milestones are binaries made for testing. They have no significance beyond that and any time spent on the branch is a division of resource that only makes sense as a means to make this Milestone better than the last so that people will use it more than the last one and hopefully find bugs that they didn't find before. That you think otherwise is your misunderstanding of the purpose of Milestones and the effort that goes into making them. I was in favor of binaries but having read your comments I think I'm beginning to see the logic in the early arguments against providing binaries. (mozilla.org didn't always make binaries, you know, and there was serious debate about doing so. people quickly forget that the only reason for doing binaries is to facilitate broad testing and development). If you think that the total number of reports in our bug database is _the_ quality metric for mozilla you are far from understanding this process. How about the number of blockers today compared with a week ago? Is that not a quality metric? How about the average severity of incoming bugs going down? You don't consider specific quality metrics as valid and you insist that total reports in the database is valid quality metric? Mean time between failure isn't a quality metric? If you've got ideas about measuring quality that are any more sophisticated than total bugzilla report counts and if you'd like to do some measurements let me know. I can use the help. If you want to insist that you have better idea about the quality of the app that I do but can't provide any numbers or that the app's quality is somehow going down then this is a waste of my time. Thanks for the help with our schedule. I guess we're long past 1.0 then. The marketplace (companies like Beonex, Netscape, Bloomberg, ActiveState, iPlanet, Galeon, Nokia, Intel, HP, RedHat, IBM and other) have been using Mozilla for a long time. Since they didn't reject Mozilla I guess we meet your criteria for 1.0 (hell, we met that years ago). (1) Many commercial developers and development companies are devoting resources to support Mozilla-based products (Netscape, Nokia, iPlanet, RedHat, Intel, IBM, ActiveState, OEone, HP, others). Many are already shipping products based on Mozilla (Netscape, iPlanet, RedHat, IBM, ActiveState, others). (2) mozilla.org has no intention of "shipping" a product that will be "a significant force in an IE-dominated marketplace". We'll leave that to big companies with marketing and distribution budgets. I can think of a couple and neither of them are waiting for Mozilla 1.0 to start that effort. So, I guess 1.0 is done. We should retroactively rename 0.6 or 0.7 to 1.0 and get the show on the road to 2.0. You're flat wrong about the Bugzilla and QA activities. It is the unpaid volunteers that triage the overwhelming majority of incoming reports. You're also wrong about "regression rate". What methods are you using to determine that there is a high regression rate? What do you consider high and what metrics support that conclusion. You want to give us a list of all of the regressions that made it into some of the Commercial releases based on Mozilla code? Let's look at Netscape. Can you point me to all the regressions in 6.2 vs 6.0? Is that number unacceptible? Your're also wrong ab out another point. Lots of people do QA for fun. Some of them are paid, some are not. I happen to be someone that does it for both reasons. Do you have some statistics that demonstrate that "No one does [QA] for fun."? Most of the people I've met in QA are there because they enjoy it. Maybe enjoyment is not the same as fun? I'll look up the word origins later. Is QA such a shitty job that people doing it couldn't possibly do it because they enjoy it? There are other jobs that pay the same or better and require less effort and education. What do people do QA if it is so not fun? That they can publish and you can read an admittedly "rumor mill" editorial on news.com has nothing to do with any pressures we face to ship an app. If you believe that AOL is putting pressure on mozilla.org to ship 1.0 you are really out of touch with the relationship that Netscape/AOL have had with the Mozilla project over the years. I'm very close to being done with this thread. You are offering nothing . You criticize the people and the process and don't offer any alternatives and definitely don't offer to pitch in yourself. You don't understand that we're building a technology that others will take to market. I think I remember you saying that you felt you got burned by getting involved with Mozilla early. It's a shame that you invested before the technology was up to the level you needed it to be. Others invested early, actually paying people to fix the bugs that blocked their particular projects and their efforts are paying off. Talk to ActiveState or Netscape or OEone about their experiences as early adoptors. They all have great products based on Mozilla technologies. Others are doing the same and it gets easier with every passing day. If you don't think Mozilla is good enough for your particular needs you could pay some folks to do development and QA, you could wait until someone else does that work for you or you could find a different solution. I'm glad to help you pursue any of those options. --Asa #103 Re: you obviously haven't been paying attentionby strauss Tuesday September 11th, 2001 8:21 PM I have been paying attention. The project has run way short on bug-fixing goals with most milestones. Even after a mass postponing of targeted bugs to the next milestone, the milestone is often closed with more than a hundred targeted bugs still unfixed. Saying this isn't a problem is just not right. No one expects every targeted bug to be fixed, but the documented performance is not even close. Number of blockers is not a good quality metric since the bug queue is largely unevaluated. If duplicates can't even be pulled out, and there are thousands of bad bugs in the queue (as you keep telling us when you say the bug queue doesn't matter), that means no one knows how many bugs should have been considered blockers, because many of the bugs have not been evaluated yet. Average severity of incoming bugs is a good but limited metric. It's limited because, again, incoming bugs are not checked, so their severities aren't reliable; and because bugs need to drop across all severity levels, not just the most serious, in order to create a professional-quality product. A product with no crashers but thousands of cosmetic problems is still a low-quality product. Mean time between failures, where failures means crashes that were reported, is not a good metric at all. The system shouldn't even be crashing often enough to make this a relevant number once you get to beta. It's a very blunt metric that only covers a certain kind of defect. You could take it to infinity without having a shippable product. (Incidentally, where are these metrics listed? I just searched for mean time between failures on mozilla.org, and went through a ton of QA FAQs and related documentation, without finding them.) Again, citing a bunch of "products" that have gone nowhere in the market is irrelevant. How satisfied do you think Netscape is with the ~0% market share on Netscape 6.x? The fact is that no Mozilla-based product has yet been taken up by end users in any significant number. The reason for that is that Mozilla isn't ready yet. You acknowledge that yourself by declining to vet any version so far as 1.0. I've discussed regression rate before. Try this: http://bugzilla.mozilla.org/reports.cgi?product=Browser&output=show_chart&datasets=REOPENED%3A&links=1&banner=1 QA is not fun. It's hard work. Your QA process, which is based on the proposition that QA is fun, is failing. This is demonstrated by the fact that by your own description, you can't evaluate your defect curve because there aren't enough people to look at the incoming bugs. You could fix that by having AOL throw a little money and a few resources at the problem -- by my estimate it would take about three months and five hundred thousand dollars to get the bug queue to a reasonably evaluated state. Not a huge expenditure for a critical task for a major software project. But you can't even consider that maybe the open source method isn't working here. That's an article of faith that must never even be questioned. We did pay to fix bugs in Mozilla. Lots of them. We got absolutely nothing out of it, because Mozilla support is still, a year later, totally irrelevant to the market. Dirty little secret about open source: it subsists on handouts, and gives nothing back. More and more companies are finding that out. IBM may finally find a way to do something with the model, but no one else has. All open source companies except a few mom-n-pop consultancies are losing money. And again, there's only so long AOL is going to continue to fund you if Netscape 6.x doesn't start to gain some market share. It's expensive to pay for all those developers and AOL is in an ongoing cost-cutting regime. to tell for example me that QA is not fun even if I love it? Who knows better what is fun for me....you or I? It's still me so shut just up. Just one question: wherefrom do you have your numbers? How do you know that for example Komodo has no significant market share? How do you know that say Red Hat or SuSE does not get any money from open source distribution even if they actually yield profits? How do you know that open source does not work even if KDE and Gnome beat every single Desktop out there in terms of not only skinability and visual effects but in good software design, good component model and just supporting my work? And at last: it doesn't matter what you say about the quality of Mozilla. I'll continue using it cause it is the most stable browser I've seen yet (this mean time between failure you say that it doesn't care you know...), has some functionality that I would miss in some other browser, looks best of all and supports my vision of a standardized web. QA may be fun for you as it's done on Mozilla. That may have something to do with the fact that it doesn't hold you to a standard -- such as whether all the incoming bugs get looked at. I'd say that's not QA. Komodo is not a force in the industry. I know that as a developer. Feel free to demonstrate otherwise. Feel free to demonstrate that there is significant market share for any of the "great products" mentioned. Red Hat and SuSe are not profitable. They have never had a profitable quarter, in fact. Oops! Strauss is wrong again. Redhat has now had a number of profitable quarters. Acquisitions make it look like they haven't, but in fact including capital incomes they have. No, Red Hat has never had a profitable quarter. Guess what: acquisitions count on the bottom line. http://biz.yahoo.com/p/r/rhat.html Ooops. Sorry. I forgot in your world you want companies to wait to the end of the quarter to buy companies, offer new services, and add worth, because then you would call them 'profitable'. So no, you're wrong. Acquisitions count for some things and not for others. Some call things profitable if their capital gains and income outway outgoings, some ignore capital gains. Either way you look at it is semantic, though - Redhat have made money, are selling enough products to pay for what they do, etc. You're also forgetting that income from bought companies tends not to topple over in various measures to the company that acquired them until a quarter (or even two) later. Luckily you're not an investment banker, because that professsion works on less simplistic grounds. Companies often reports conditional profitability based on, for instance, ignoring "one-time non-repeatable expenses." There are SEC standards for accounting in annual and quarterly reports. These standards were created in order to eliminate ambiguity and number-fudging, and to give investors a reasonable standard for evaluation. Under the SEC standards of accounting, Red Hat is not profitable. Its statements indicate that it does expect to become profitable this year, though. If it achieves that goal, we can then look at how much Mozilla contributed compared to how much it cost, though some degree of guesswork would be involved. #110 Re: Re: you obviously haven't been paying attentioby asa Wednesday September 12th, 2001 11:48 AM "You could fix that by having AOL throw a little money and a few resources at the problem" If this is true it is also true that you could fix that by having your company throw a little money and a few resources at the problem. Why don't you convince your comany to toss in half a million dollars. "citing a bunch of "products" that have gone nowhere in the market is irrelevant." I disagree that these products have gone nowhere. I don't think that market share is a fair measure of quality either. There are plenty of superior products which never become market leaders. "you can't evaluate your defect curve because there aren't enough people to look at the incoming bugs" Your proposition that the only measure of the quality of a product is a defect curve is wrong. Your suggestion that our quality has gone down because the number of known issues has gone up is wrong. "I've discussed regression rate before. Try this: (LINK)" You don't even know what that means. Reopened Status is not equivalent to regression. A significant percentage of those bugs are reopened for continued work. Unfinished work does not equal regression. You want us to change our catagorizations so that they fit your definitions so that you can more effectively criticize the progress we're making? Do you really believe that the codebase is of lesser quality than it was a month ago or 6 months ago or a year ago? Strange how everyone else disagrees with you. " Dirty little secret about open source: it subsists on handouts, and gives nothing back." Then why are you still involved? Just can't get enough of the one way street? "It's expensive to pay for all those developers and AOL is in an ongoing cost-cutting regime." I'm sure you have more insight into AOL than I do so there isn't much I can say here except that AOL is a major contributor to the project I work on and it would be a shame to see those contributions end. I hope they don't but I did't start working on this project because of AOL's contributions and I won't stop working on it if those contributions come to an end. I'm done arguing with you. You obviously have a chip on your shoulder and it's a waste of my time discussing this with you since your only specific proposal seems to boil down to tossing out open source and magically creating half a million dollars for bug triage. That's not likely to happen so if you're sitting around waiting for it then get a comfortable chair because you're gonna be sitting for a long time. --Asa #112 Re: Re: Re: you obviously haven't been paying atteby strauss Wednesday September 12th, 2001 12:10 PM This is just another flame. There's no substance. You didn't even answer the question about where to find the quality metrics you cited. Do they exist? If so, where? To answer the one point in your message that was specific enough to respond to: yes, reopened bugs and the regression rate are very closely linked. QA-savvy individuals frequently use the Reopened line as a bellwether of overall product stability. #114 Re: you obviously haven't been paying attentionby DavidGerard Wednesday September 12th, 2001 6:57 PM Asa said: >>"Lots of people do QA for fun. Some of them are paid, some are not. I happen to be someone that does it for both reasons. Do you have some statistics that demonstrate that "No one does [QA] for fun."? Most of the people I've met in QA are there because they enjoy it. Maybe enjoyment is not the same as fun? I'll look up the word origins later. Is QA such a shitty job that people doing it couldn't possibly do it because they enjoy it? There are other jobs that pay the same or better and require less effort and education. What do people do QA if it is so not fun?"<< Heh. I'm thinking of a friend of mine who does software testing for IBM. As she put it: "It's amazing. I'm actually being paid and *appreciated* for being a nitpicking pedant!" #115 Re: Re: you obviously haven't been paying attentioby strauss Thursday September 13th, 2001 11:56 AM Please note that your friend is not doing it for fun. She is being paid by IBM. That of course does not mean there is no enjoyment in it, and my statement should not be construed as saying that QA is a miserable career. In any job, there are both pleasant and unpleasant aspects. The problem with the open source model is that there is no particular incentive or compulsion driving people to engage in the unpleasant tasks, which are equally necessary to project success. For instance, left to their own devices, most people would rather create their own bug reports than investigate others'. #100 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: The Poby SmileyBen Tuesday September 11th, 2001 5:13 AM You are so far out of line it's not funny. You are being rude and disrespectful to a large number of people who give up their time to make a piece of software for the common good. Asa is here giving comments and feedback out of the goodness of his heart, and you presume that you have a god-given right to it, to make demands of him, and to make sideswipes about the very culture of the movement everyone in mozilla is working in. No doubt you won't see this, you'll consider your behaviour perfectly reasonable, and you'll attribute this outburst to people disliking negative feedback. With all due respect, that's bulls**t - it is the way you do it, not what you say that makes you so out of order. As to your comments, even if they were voiced acceptably, I think the central point is way off base. If the favourite browser for windows on, for example, download.com, rating higher that IE6, is 'rejected' by the general public, then you must have a very bizarre idea of what acceptance is. Have a look at the comments and feedback (and number of thumbs up), and then come back and tell us now is too early for a release. Or, equally, don't bother. #102 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: The Poby ogiesen Tuesday September 11th, 2001 7:46 AM Have you actually used any of the last ten milestone releases? Ever since 0.9.1 Mozilla has pretty much become my browser of choice for all my browsing needs, although I haven't reconfigured Outlook to use Mozilla to open http-Links, yet. This way I'm using IE 5.5 and Mozilla at estimately equal parts, and since 0.9.3 I have the definite feeling, subjective as this is, that IE crashes way more often on me than Mozilla does. Note however, that I'm only using the Browser bit, no Mail/News or composer stuff due to company policy (Outlook). And yes, of course, the bug curve counts! But you're making it far (far, far, far, FAAAAAR) too simple for yourself if you just put the total bug count on the Y-axis. The only thing the resulting curve really signifies is traffic. If it's steep, it only shows that the number of people actively using Bugzilla is quite high. Please, only once, take the time to actually READ and digest one of Asa's posts word-by-word. I find it absolutely astonishing that he still manages to keep half-way calm and objective in the face of your total arrogance/ignorance/rudeness. I would never have thought it possible that one day I might feel the NEED to get personal in a technical discussion but that just goes to prove how wrong one can be... so here it is: YOU SUCK! Oliver(feeling slightly better now) There needs to be a culture of support AND criticism. The volunteers need to know that they're doing a great job (they are) but there also needs to be an awareness that improvements could be made (they always can), there are bugs (there always are) and they need to be made aware of where these areas lie. There is always work to be done. Also something to keep in mind is that objective criticism of Mozilla the project is not the same as personal criticism of a volunteer. You can have a team of incredibly hard working forest fire fighters struggling to put out a fire - and each one of them may be doing an amazing, super-heroic job - but that doesn't mean that the fire will be put out or the forest saved. There can be failure despite incredible effort. I think that people who criticise need to do so in the same breath as giving praise. (Too often in our society, only the negatives are mentioned.) At the same time, the volunteers and those who DO deserve praise need to be a bit less sensitive towards objective criticism in general. Jason. You're absolutely right, mozilla does need criticism in the sense of people telling them what's wrong with it. In fact, it needs mozilla.org to request criticism from the public. And, hoorah, they do. It's called bugzilla, it's the single more critical thing you could say about mozilla, the people working on mozilla read every word and anyone can contribute. Cool, huh? Bugzilla allows for criticism in the sense of reporting, and working on fixing, bugs. It does not, however, offer itself as a forum of (critical) discussion of the management, direction, vision, what have you, of the Mozilla project as a whole. Bugzilla works in terms of "in the trenches" tactics - not overall strategy. Discussion of the merits of something is not allowed there. Jason. I can see your point. Imho, the "problem" is that what you are trying to do would work better on a first person talk (I mean direct conversation) between people that know each other and work on the same group or project. And, of course, we cannot neglect cultural differences. Speaking a bit more technically now, many people insist in UI and it's own problems (which, admittedly, are too many) but fail to pay attention to the enormous job on the backend of the application. On the management side, I do share your's and strauss's concerns about q&a (or even every kind of human resource) restrictions in this project. But how much of *our* time do we spent for Mozilla ? Many Mozilla.org people (e.g. Gerv) are just volunteers. So, until we can find more time to share for Mozilla, we must keep our criticism low. Your anonymity is another issue. I suppose you want to avoid potential flames or spamming. Obviously, I can't blame you for this, because I follow the same practice (but you can easily locate my real address in Bugzilla :-)) Thank you for your answer and sorry if I was somewhat rough on you in the past. >I've seen the same extrapolating tendencies in many comments > to strauss' posts.. The main difference being that you are describing yourself as a supporter of the project and do actually offer constructive criticism most of the time, however offensive this may seem to some people. strauss' statements are astonishingly lacking in credibility because there's no hint that he has actually USED Mozilla anytime in the last 18 months. His excessive bitching about bug numbers almost makes one wonder if he and mangelo might in fact be the same person after all. Oliver What sort of a "site" doesn't use cookies and IP tracking for polls than? I do believe that cookies ARE used. But what's stopping someone from writing a script that just doesn't accept cookies? Or accepts, but then deletes and votes again. And IP tracking? So you mean that only one person per ISP / company proxy can vote then, eh? Most companies are behind one IP address these days - either because of a NAT / firewall / proxy / combination of these. For ISP's, there might be a handful of proxies, but the result is the same. You can't block votes per IP.... it can be triggered. e.g. if more than 10 votes given from same IP, there is a something to wonder. Also voting can be non-allowed to people who didn't turn on cookies (some of my friends never used a cookie in their lives) So, a question (for me, real funny) asked there, people voted than it showed the very own Mozillazine as the worst news choice ;-) Polls are never scientific but let me laugh ;-) As I know people mailing the Register to remove mozillaquest link from a story they UNCOVERED (notice the difference, uncovered) themselves from here, it wouldn't surprise me if that poll was removed from site in hours ;-) I agree to a comment I have read, poll should have been named "Do you hate Mozillaquest which should be hit by a bus?" "YES/YES" decisions, uh pardon... "yes/no". Thats the freedom of speech in lizard's understanding ;-) "it can be triggered. e.g. if more than 10 votes given from same IP, there is a something to wonder." So if more than 10 people from Nokia want to vote.. you'll just block the rest. Interesting. I bet everyone from Netscape come from one IP too. "Also voting can be non-allowed to people who didn't turn on cookies (some of my friends never used a cookie in their lives)" Easiest thing in the world to write a script that accepts cookies, votes.. then forgets the cookie and votes again, accepts the cookie so that it's allowed.. Then forgets it when it'd done voting.. and votes again.. etc. "I agree to a comment I have read, poll should have been named "Do you hate Mozillaquest which should be hit by a bus?" "YES/YES" decisions, uh pardon... "yes/no". Thats the freedom of speech in lizard's understanding ;-)" Yes, unfortunately, I've found that that *IS* the freedom of speech in the lizard's understanding.. :/ "Open source, closed minds".. You've heard that before, I'm sure. <quote>Yes, unfortunately, I've found that that *IS* the freedom of speech in the lizard's understanding.. :/ "Open source, closed minds".. You've heard that before, I'm sure.</quote> Ok, so how is that not dissing Mozilla *people*? Last I checked, the product didn't have a mind. "Ok, so how is that not dissing Mozilla *people*?" That was a sarcastic remark about how people on MozillaZine can't tolerate any negative opinions. It has nothing to do with the Mozilla product or the developers of Mozilla nor their efforts. It was a comment about silly MozillaZine posters who think this is some kind of Jihad and put a Fatwah on me for mentioning anything negative about Mozilla or anything remotely related to it. Ilgaz commented jokingly on how "that *IS* the freedom of speech in the lizard's understanding" and I found it pretty ironic since it's quite true, at least on MozillaZine. The "lizard's opinion" seems to be finger pointing on anyone who dares to say anything negative about Mozilla. Lighten up a little, why don't you? I don't think I post with any opinions. I'm not seeing the "MozillaZine can't tolerate any negative opinions." Are you saying that this site (others and I) are purposely posting bias news? What news did we miss? Compare this story about the upcoming milestone to others sites. I'd say other than the last sentence which was my opinion, it's pretty much all fact. Perhaps I should not have included the last sentence in the item, you tell me. I think you're mistaking peoples opinions in the talkback of articles as MozillaZine news. You have a negative opinion of many of the things going on in the project right now. Others do not. Because the majority of the people agree with what's going on, you think it's "biased." I think people just don't agree with your opinion. >> What news did we miss? << How about the Mitchell Baker layoff? How about the ever-escalating defect curve? How about the user adoption figures for Netscape 6.x? Feel free to point me to these stories. >> Because the majority of the people agree with what's going on, you think it's "biased." << I think the poll may show a different story when it comes to lurker opinion. Story one, part of http://www.mozillazine.org/talkback.html?article=2002 . Story two, not a story. If you want us to each day say "more bugs filed" then that's just silly. There are two factors at work here. One, more people are using Mozilla, and that is driving the number of bugs higher, which comes into play with Two, the quality of bugs is dropping. I have a hard time when people keep moaning about bug count numbers taking them at all serious. Use the product. Thats how you know if it's good or not. Not by the bugs filed by others. Story 3, I haven't seen any data on this, nor has anyone submitted it. The site works on the basis of either I find news, or someone submits it. If both of those methods come up with no hits, you won't see news on the site. Sorry, I can't work magic. As far as the poll goes, one person decided he should vote 200 times for one site, so I think it's even less accurate than normal. How do you define defects? Every bug is not a defect. All bugs are not equal. As time goes on, the bugs tend to get more nitpicky. In the past, crashes were a very common reason for filing a bug; now bugs are more likely cosmetic or related to adding new features. I'd rather have a browser with 1000 cosmetic bugs than one with a single frequent crasher bug. This "ever-escalating defect curve" is a bogus statistic. "I don't think I post with any opinions." Well, I don't know who did the vote about the worst Mozilla news site, but that was pretty lame. Naive, lame.. to the extent it wasn't even funny - just plain lame. "I'm not seeing the "MozillaZine can't tolerate any negative opinions."" Well, I didn't mean the site. I meant the users.. And of course one shouldn't generalize. :) "Are you saying that this site (others and I) are purposely posting bias news." Yeah, that was my contention.. But it's not really that you've missed any important piece of news. It's more like.. that there aren't any serious discussions about the obvious issues that there are. UI quality for one. Marketshare (or lack thereof) being another.. and so on and so forth. What I mean is that we mostly just see "0.9.x released!!!" here, while MozillaQuest would post the same thing, but with "0.9.x released, behind schedule and with 3123 bugs, 1239 in X, 1234 in Y, 9123 in Z". :) But then again, like I think you (?) have pointed out in previously, people are free to post their own stories and you'll publish them if they are good.. So.. If i feel so strongly about these issues, I guess I should write an article. After all, this is a community effort. "I think people just don't agree with your opinion." Really? You think? :) Well, compare the more widespread views of users of MozillaZine with the general public and you'll find that my views much closer reflect the general public. In that sense, MozillaZine (the users) are pretty biased. It's quite understandable though. People read this site because they are enthusiastic about Mozilla. Of course you'll find a pro-Mozilla bias! I wish people would have more tolerance for eachother though. All good points. As far as the poll goes, we wanted to have a bit of fun. It backfired, and someone decided to ruin it. As far as discussion of UI and other product design and implementation is concerned, right now, most of that discussion goes on in the newsgroups, which is really where it should be. For UI bitching and moaning, which I love to do, we're still working on getting forums up for people to create their own topics :). I know the site has been pretty stagnent in recent months, but we're trying hard to get it all up to date one piece at a time. We might even get the screenshots updated this week, for all the people who hate us for letting them grow old :). Jason <quote n=1>Yes, unfortunately, I've found that that *IS* the freedom of speech in the lizard's understanding.. :/ "Open source, closed minds".. You've heard that before, I'm sure.</quote> <quote n="2">I'm not seeing the MozillaZine can't tolerate any negative opinions.</quote> <quote n="3">Well, I didn't mean the site. I meant the users.. And of course one shouldn't generalize. :)</quote> Ok, so "the lizard" = "MozillaZine posters?" I'm not getting a "true" return on that test. Was it a gigantic mistake for Netscape to release a browser based on a pre-1.0 Mozilla? Possibly. Has Netscape been gradually losing marketshare ever since 4.x came out because Netscape 4.x isn't as good a product as IE 4.x, 5.x, 6.x? Possibly. Is everyone who reads MozillaZine happy with the product as it is today? Definitely not. But if there's no free speech on MozillaZine, how come you're here? As for MozillaQuest, come on, it should be obvious to you that MozillaQuest is simply a gigantic flame; even your opinion (macpeep) is higher (and it is rather better informed). I've been using the 0.9.4 candidates the last few days and unfortunately it seems that memory leaks have regressed seriously. I'm exceeding 100MB of RAM usage very frequently, while with 0.9.3 I was usually between 60-80MB. Right before posting this, I reached 150MB and had to kill the lizard because it froze at a particular page... Sorry I can't be of any particular help by pin-pointing reproducable ways (-I don't know of a "methodology"), but I thought you may find this useful anyway. Sort of relevant, but maybe not: People have posted complaining about Moz's humongous footprint before, and more than once, the reply has been "RAM is so cheap nowadays. Go buy some more". But who are we to force users to buy more RAM? They'll just go to something light(er) like IE (because it *appears* to require less memory) or Lynx (heh). Running Mozilla on Windows 98+ systems (and >90% of the world uses Windows nowadays, even though many Mozilla coders are using Linux) is like running 2 browsers at the same time (because of that pesky IE) - the RAM requirement is ridiculous. Result(s)? Crashes, freezes, slowness et al. Granted, not everyone runs like 6 programs at startup and which reside in memory (I'm a utility freak), but I still think we should get the footprint DOWN. I'm currently using IE6 on Win2K and task manager is reporting: Mem Usage: 12840 K and VM Size: 4072 K The Process Viewer tool that comes with Visual C++ and reports the RAM usage of every single resource used by IE - all ActiveX controls it uses, all DLL's etc. reports a total of 23696 K at "User Address Space" at this moment, while I'm writing this. Virtual Size is 70556 K and the working set of that is just under 13 megs.. So in other words, the part of IE that is in RAM (not swapped out) isn't actually that large at all - *MUCH* less than for Mozilla. Can anyone tell me the quick way to suppress popup windows? I can't find it in the latest release notes. The last time I tried it(about a month or so ago), Mozilla kept rewriting my prefs file and removing it. http://www.mozilla.org/projects/security/components/configPolicy.html has this and much much more. --Asa The simplest method is http://groups.google.com/groups?hl=en&safe=off&selm=3B8FEF23.5010505%40netscape.com There's a nother method which has already been posted. It gives more control but it takes a bit more maintenance. I would look at the above first and, if you need more control, go on to the other one. Getting this to work properly, and with an easy interface, is still in process. Jason. Actually the taskbar icon can be very powerful, it is not at this point. Now I know everybody works on fixing the bugs and this should be the main thing, but here is what is missing featurewise: These are mostly things that I want on the taskbar icon, without opening a netscape window. 1) When I restart the computer (or login to my account), I want the preloader for mozilla/netscape to run aumatically and display an icon in the taskbar. I hope that is done. 2) Automatic email check. I want this icon to check my emails and warn me about new emails, number of new emails etc. I want to be able to right click taskbar item and select "create new email". 3) For Netscape: I want the instant massager to login to my account automatically (similar to the real aim client). I want to be warned if people are online in the taskbar, and I want to be able to right click and select people online to send a message. 4) Multizilla is great. Not related to the taskbar though. Just a thought - if everyone is worried about the addtional seconds and RAM that -turbo mode will take up, why not make the Mozilla installer check how much RAM the machine has and how fast it is and then use that info to determine whether -turbo (Quick Launch) is ticked on by default in the installer dialog or not. It could then say: Your machine appears to be quick enough and have enough RAM for us to recommend that you use Quick Launch by default. [The Quick Launch option would be ticked on by default] or, if it's not good enough: Your machine isn't fast enough [or your machine doesn't have enough RAM] for us to recommend that you use Quick Launch by default - we suggest that you leave Quick Launch disabled. [The Quick Launch option would be ticked off by default] This would stop a certain naysayer with the initials MA from whingeing about Quick Launch being the default when 0.9.4 comes out - it would be only the case for machines that were considered beefy enough to not impact on overall RAM or startup time too much. Mozilla lacks extended option for 'no proxy for'. You can set .domain.com but you can't set something like 192.168. Kosc |