Minutes of the mozilla.org Staff Meeting of Monday 28th April 2003
Friday May 2nd, 2003
The minutes of the mozilla.org staff meeting of Monday 28th April 2003 are now online. Issues discussed include 1.4 Beta, 1.3.1, Mozilla Firebird 0.6 and 1.5 onwards.
* Done and sitting on the staging server.
* Asa needs to update the release notes and do an announcement.
* Done by the end of today."
That was the 28th of April, it's now the 2nd of May. Has someone forgotten update the website and the FTP server?
"Mozilla Firebird 0.6
* It's been ready for ages
* Definitely better than 0.5
* David Tenser is busy doing the documentation for the release
* Likely to happen in the next week or so"
Let's not forget that Mozilla-Browser/Phoenix/Mozilla Firebird hasn't had a proper release for about 6 months now. Roll on 0.6!
Happy to read this stuff, sound like going in the right direction
#4 no feature parity ?
Friday May 2nd, 2003 7:24 AM
"Firebird will never have feature parity within itself, because that would be a bug — extensions are the key"
what does that mean ? "feature parity" ?
feature parity - provide all the same features as...still not sure what he means
Feature parity means "having the same features". That sentence isn't clearly written, but they're saying that Firebird will never have all of the same features as the current browser part of Mozilla (Seamonkey). The features that don't go into Firebird will instead be extensions.
#10 discussion with nice explanation by Asa
Friday May 2nd, 2003 8:14 AM
#20 I doubt many people disagree, but....
Friday May 2nd, 2003 4:27 PM
I think pretty much everyone will agree with the conclusion of that discussion. About:config is the place for the multitude of really niche, specialist prefs, and experts should use that. Also, about:config could be a lot more useful if it were searchable, organised into a tree, etc.
BUT, and this is the important bit, even if we agree we need fewer exposed preferences, we still need the right ones. I couldn't say it better than the person that points out that 'open tabs in the background' is no way more important as a pref than, say, image resizing, smooth scrolling, or stopping target=_blank (especially since that one on its own gets in the way of any serious tab-user).
Think about it this way: if you open tabs in the background, as should be the default, you could open fifty tabs and still keep going (well, except for screen spaces), but if you don't open in the background, well, that would be exactly the same as opening a new tab in the background, then clicking in that tab. No problem. Not much more effort, unlike replicating the opposite behaviour - imagine trying to open fifty tabs if you had to click back *every* time. So almost everyone will use the first, sane option. We still want the possibility to change it if it really annoys you, but that's what about:config is for.
On the other hand, *plenty* of people will want to stop image-resizing or smooth-scrolling. Actually, if they didn't the only reason would be that they thought they were stuck with one behaviour. Clearly *these* options should be easy to change.
And no, I'm not saying the options should be the ones *I* want, I'm saying we need serious discussion of what these should be. I'm sure serious discussion *is* occurring about exactly which ones, but I'm sure as people move over come 1.5alpha, we'll get lots of people with strong opinions on which options should be present....
Probably many people would like to see "Advanced" buttons in the Tools->Options of Mozilla Firebird / Browser. Usually only power users click on clearly marked as "Advanced" buttons, and therefore normal users are not confused by those half hidden sections, which I would like as extensive as possible. (about:config is not very comfortable, sincerely).
I believe this would be the best solution. Many other programs behave like this too, i.e. GetRight (a download manager for windows). When you install it, you can choose between an advanced GUI for experts and a more simple one with only the most important options. You can switch between the two modes later at any time.
The new Mozilla should have such an advanced mode too.
#35 Re: Separate "Advanced" options
Sunday May 4th, 2003 3:06 PM
I think about:config just needs to be made more usable (checkboxes for boolean prefs, expanding twisties for categories) and it would serve this purpose as well as any "advanced tab" could.
#22 Advanced Preferences
by pkb351 <firstname.lastname@example.org>
Friday May 2nd, 2003 7:51 PM
Here is a solution: There can be a simplified preferences window which would include a link to open an advanced preferences window. (This advanced window could be password protected by an administrator or a parent.) Those who do not wish to have advanced preferences do not need to use it. The default preference setting is good for some, tolerated by others and hated by others. A program is most usable when it is easily configurable by all users. I am comfortable using about:config, but I find it anything but easy to use, most of all when I am not sure what the preference is called.
I do not underrstand why some are so against allowing adavnced preferences (and I don't mean by access through about:config). Making browser preferences easier to use can only make the browser better. If there is a preference which may screw up the browseror cause a user major grief if the user does not know what they are doing, then leave it out and very advanced users needing that preference can go to about:config. For more useful advanced preferences, such as Tab browsing behavior or popup windows settings users need and REQUIRE a preferences panel. about:config is only useful for preferences rarely set to anything but the default.
Now for the Tabbed browsing example: if the default is to open a link in the background and there is no option to change it in the preference the user may not realize the option of using about:config. Even when told about:config they might find it too confusing. All they want is to stop new links from openning in the background. Many users with high speed internet connections do not want a new link to open in the background. I would consider the user who wants to change how links open an advanced user. Not all advanced users are comfortable or capable of using about:config. This user requires advanced preferences.
If you fell the browser must not have advanced preferences there is a simple solution ->do not use them. For those who need advanced preferences let them have them. Please don't simply claim that everyone only need a very "simple" preferences panel. If you need anything beyond the most basic preference go to about:config.
We want Mozilla to gain in popularilty and usage. I am sure Mozilla will lose users when they inquire how to set a certian preference and they are directed to about:config. I can just hear a revier of Mozilla 1.5 stating: "Many useful preferences are very hard for the users to access. Mozilla puts many useful preferences in a very cryptic location. To access Mozilla's advanced preferences the user has to type in about:config into the url bar and hope they can find the preference in the long list, let alone how th set it. Mozilla should have an advanced preferences panel."
In case it wasn't clear, I do completely agree. What I was saying *wasn't* that there should be no more preferences than there currently are, but simply that the discussion amoungst Asa and the others linked above, with all due respect, is a little facile. Asa points out that about:config and prefs.js are the place for the hundreds (thousands?) of weird and wacky preferences that are possible because of mozilla's flexible design. I was saying that just about EVERYONE can see that most of these hundreds of preferences shouldn't be exposed to the user, because nobody is ever going to use them, except for very specialised cases. A good example are options that aid debugging the browser whilst its being written: clearly about:config may allow for easy access to developers, whilst a user would NEVER want this, and would be terrified by the sudden appearance of debug information.
But the reason this discussion is pretty facile is that nobody doubts that there are a huge number of preferences that we don't need access to, but that's beside the point. The reason that people have a problem is that loads of options that *do* need exposure aren't there. It seems bizarre to me, and presumably to the others here, that anybody should be suggesting that setting user_pref("general.smoothScroll", false); is anywhere near the same league as unticking the box that says 'Enable smooth scrolling'. If about:config was altered so that it had tick boxes and nice descriptions of the option (such as 'Stop most links opening in a new browser when you don't ask them to'), then maybe it would be acceptable, but that would rather defeat the point.
So, to try to put this briefly, yes, Asa et al., we know that there are plenty of prefs no user will ever use, nobody disputes that, the problem is that the current policy on prefs avoids loads of middle-user option, and in fact plenty of basic options, that need an easy, tells-you-what-it'll-do preference.
#7 Minutes don't follow the branding policy
Friday May 2nd, 2003 7:52 AM
These minutes refer to "Firebird" and "Thunderbird", and are so in breach of the Mozilla Branding Policy [<http://www.mozilla.org/roadmap/branding.html>], which states that they should be called "Mozilla Firebird" and "Mozilla Thunderbird".
Not really, FireBird and Thunderbird are to be used for internal discussions and development.
#12 Re: Product Names
by tomsommer <email@example.com>
Friday May 2nd, 2003 10:13 AM
Yup, and give the names a rest for christ sake! Every damn news has to contain something about the name...
#17 Minutes of the mozilla.org Staff Meeting of Monday
Friday May 2nd, 2003 12:44 PM
Explain to me now how the title "Minutes of the mozilla.org Staff Meeting of Monday 28th April 2003" with references to Firebird Web Browser as well as Mozilla in it cause confusion.
#27 Re: Re: usenet groups
Saturday May 3rd, 2003 2:04 AM
Public webpages are not internal.
#30 in open source projects, they are
Saturday May 3rd, 2003 5:39 PM
almost all "internal" discussion in open source projects is done publically since they developers are the general public.
#14 Re: Minutes don't follow the branding policy
Friday May 2nd, 2003 10:47 AM
Come on, anybody who read the Branding Policy and interpreted it as "Firebird/Thunderbird will never appear without Mozilla in front of them" is only looking for a reason to complain.
Context is everything. This was the minutes of a Mozilla staff meeting, therefore everything would pertain to Mozilla unless otherwise specified.
just this morning i was looking for an update from the firebirdSQL project, so i thought to myself: "hey! lets check mozillazine to see if there are any minutes from internal mozilla meeting!"
gosh was i confused!
The IRC client already exists as an extension to Mozilla Firebird. It just needs some more hooks for creating a menu item, prefs, and chrome. But it was fully functional and several people use it.
#11 Re: IRC is already an extension
Friday May 2nd, 2003 10:08 AM
Where can it be downloaded?
start with phoenix.exe -chat
I was just thinking that, since the milestone decision was made that Mozilla 1.5 and later versions will be based on the Mozilla Firebird/Thunderbird projects, the jump from version 1.4 might be more significant than a point release. It seems to me that Mozilla 1.5 will be a significantly large step away from 1.4 and previous versions (at the very least, much larger than the step from 1.3 to 1.4, 1.2 to 1.3, or even 1.2 to 1.4) that perhaps the version number 2.0 would better reflect the break between the "classic" 1.4 and previous versions and the Mozilla Firebird/Thunderbird-based releases. Just a thought.
1.9 might be a better designation - this allows for a "preview release" (1.9) before the first "production quality" release of the new setup. Keeping with the current path will ensure 2.0 is a significant improvement over the first Mozilla Firebird/Thunderbird release though...
#16 since there should be several milestones before 2
Friday May 2nd, 2003 11:30 AM
i think that 1.5 is a reasonable number, i think its going to take several milestones to fully flesh out the separate applications so that the are stable, feature-complete and consistant with each other enough to call them 2.0 ... but that seems to me to be the obvious end point.
A) "We're breaking interface compat with 1.0" B) "We're freezing the new 2.0 interfaces"
Neither one is happening with 1.5. Don't confuse the front end changes with the back end work that would need to happen to really make this 2.0.
Well, firebird does break some stuff - sidebars, toolbars, etc won't work without being recoded.
#25 Re: Re: Re: Mozilla 1.5 should be 2.0?
Friday May 2nd, 2003 10:49 PM
The moz sidebar api will be supported in the Mozilla Firebird API.
The toolbars and other bits of the FE toolkit were never frozen APIs. Mozilla Seamonkey themes and extensions break all the time. Seamonkey 1.1, 1.2 and 1.3 code doesn't support 100% of the 1.0 toolkit.
Boris is talking about frozen bits, primarily frozen core services (gecko, necko, etc.) We never promised a frozen toolkit, or even frozen app implementations. We've tried not to break themes too badly but even that hasn't been totally successful. But Mozilla 2.0 will hopefully also see something of a real and frozen toolkit as well (my wild ass speculation).
The move to standalone apps doesn't warrant a rev of the version number. A new version number means a new set of frozen core APIs that we haven't yet been able to make worthy of permanence/support. Should we saddle ourselves with maintaining and supporting a bunch of not quite 2.0 quality gecko APIs for a year or more because mozilla.org's Gecko-based apps have some new XUL and themes? Revving a bunch of still not ready core APIs because app look and feel (and some functionality) has changed doesn't make a lot of sense.
#26 Re: Re: Re: Re: Mozilla 1.5 should be 2.0?
Saturday May 3rd, 2003 1:52 AM
That is the info that is missing - how much will be reimplemented? There is no detailed information about this. Sidebar needs lovin no matter what though (chrome sidebars via xpinstall and the general suckiness of the current sidebar code).
I have a toolbar that works fine since 0.9.4, so we don't break all the time. Themes are a different issue :)
>The toolbars and other bits of the FE toolkit were never frozen APIs. > Mozilla Seamonkey themes and extensions break all the time. > Seamonkey 1.1, 1.2 and 1.3 code doesn't support 100% of the 1.0 toolkit.
Exactly the reason why I have stopped developing my "toy" add-on. It sucked to have to rewrite (tiny bits) for every single Mozilla release. API freeze for the foundations is a good thing. But only for guys who do a "total conversion".
Although Mozilla has quite a fan base, it would have attracted more free programmers, if it made 3rd party add-on seasier. Of course that would only benefit Netscaape/AOL as a kind of image improvement in certain circles.
Why does the F**** talkback don't honour my line breaks. How am I supposed to do decent quoting?