2004-03-29 - Summary of mozilla.org staff meeting
Gervase Markham
-------------------------------------------------
Present: scc, gerv, chofmann, asa, mitchell, blizzard, leaf, bienvenu,
bart, myk, jstl, peterv.
*Mozilla 1.7 final*
- We are frozen.
- The branch schedule is being worked out by drivers
- Asa's plan: slip branching out a week, do 1 month of development on
branch with 2-weekly release candidates
- Motivation: 1.7 is the next long-lived milestone branch (1 year after
1.4)
- There are a number of people who want to do significant releases
sooner than 1.8
- To get that, we need more time on the trunk to get a hold on
stability, respond to talkback data, clean up Bugzilla
- That would mean branching next Friday instead of this Friday.
- Target release in mid-May instead of mid-April
- Proposal sent to drivers. Will be pushed to newsgroups and Mozillazine
as a plan as soon as drivers sign off on it.
- Once on branch, use extra time to continue tackling stability,
dataloss, migration (from 1.6, 1.4).
- We think this means that the schedule slips by about a month.
*Talkback*
- Good data in from the beta
- Talkback is now in Linux Firefox nightly builds
- Leaf has Windows automation on Seamonkey - all we need is to get the
installer scripts to install the Talkback component
- Linux shouldn't be far behind. Should have nightlies tomorrow.
- We've contracted jpatel to work on Talkback data reporting and
analysis.
- We've got bug fixes in for 7/20 topcrashers from 1.7 beta.
- Asa is organising a community QA crash bug triage effort this week.
*Evangelism*
- Focussed effort in evangelism and topsites for 1.7
- Get a sanity check on where we are - bclary to help.
- We are using the Alexa list, which they publish.
- There is a top100 keyword we'll revive.
- Should we publish a list of topsites we don't work with?
*Firefox 0.9*
- One major piece of feature work left to do - extension manager UI
- Current plan calls for a release in 1st week of May; this may change
if Mozilla schedule changes.
- Coming off the 1.7 branch, probably on the far side of the 1.7
release.
- 0.9 will be feature complete; rock-solid stability is the next target.
*Thunderbird 0.6*
- All features in except Pinstripe theme for OS X
- Hopefully landing tomorrow
- Release scheduled for mid-April
- Again, plan to ship from 1.7 branch, pre-1.7
- Waiting for a little more stability
*Mozilla Foundation*
- Board meeting on Wednesday
*Merchandise*
- Firefox t-shirts - pre-orders up tonight!
- Firefox polos and t-shirts, stuffed Firefoxes (!), Mozilla polos and
t-shirts.
Gerv
Jack Tanner
> *Firefox 0.9*
>
> - One major piece of feature work left to do - extension manager UI
Remember http://tinyurl.com/38a7l? My apologies: I don't want to sound
like a broken record, and I don't mean to say that Firefox developers
should be beholden to the whims of J. Random Idiot User. But let me
reiterate: why is there any need for an extension manager with its own UI?
As you answer the question, consider two Windows UIs that are in the
same genre: Control Panel's Add/Remove Programs, and Internet Explorer's
Internet Options, Settings, View Objects. Behold the two attempts of a
corporation with a huge usability testing organization at addressing the
same problem, and tell me how useful and successful they are, and why we
would expect Firefox's to be more useful and successful.
-JT
Robert Mohr
I am not very familiar with the Windows Control Panel, but I remember
that the Add/Remove programs dialog worked fairly well. I haven't used
IE since around version 4.0.
And many other people bring up points in the thread you link to, but you
don't attempt to refute their claims.
--
Robert Mohr
moh...@osu.edu
mo...@cis.ohio-state.edu
Mooquackwooftweetmeow
> Gervase Markham wrote:
>
>> *Firefox 0.9*
>>
>> - One major piece of feature work left to do - extension manager UI
>
>
> Remember http://tinyurl.com/38a7l? My apologies: I don't want to sound
> like a broken record, and I don't mean to say that Firefox developers
> should be beholden to the whims of J. Random Idiot User. But let me
> reiterate: why is there any need for an extension manager with its own UI?
>
There's going to be a complete reorganisation of extensions in general,
including automatic upgrading; an UI for this isn't absolutely
necessary, but if it wasn't there Ben would be pestered about it until
there was. Besides, if info exists, why not display it? - extensions are
designed to be the user's concern.
-- Greg “Anselm defines God as ‘The Twaddle - Est. 2005’” Nicholson
Laurens Holst
> There's going to be a complete reorganisation of extensions in general,
> including automatic upgrading; an UI for this isn't absolutely
> necessary, but if it wasn't there Ben would be pestered about it until
> there was. Besides, if info exists, why not display it? - extensions are
> designed to be the user's concern.
Sounds exiting, I'm looking very much forward to this :).
So, it should be in 0.9 already eh?? Wai ^_^!
~Grauw
--
Ushiko-san! Kimi wa doushite, Ushiko-san!!
Jack Tanner
> There's going to be a complete reorganisation of extensions in general,
> including automatic upgrading; an UI for this isn't absolutely
> necessary, but if it wasn't there Ben would be pestered about it until
> there was. Besides, if info exists, why not display it? - extensions are
> designed to be the user's concern.
The lauded development model for Firefox is predicated on strong
ownership. If Ben doesn't feel an extension manager UI is necessary, he
need not implement it.
Is an extension manager UI necessary? Any additional UI additional costs
-- bloat at the byte level, and, even more importantly, bloat at the
user experience level. The question is whether the user experience bloat
is worthwhile. "If the info exists, why not display it?" Because the
user's task focus is to browse the friggin internet, not to worry about
extensions foo v0.1alpha and blah v0.2beta.
Could the extension manager offer some functionality not available
elsewhere? On Windows, software can be uninstalled using Control Panel's
Add/Remove Programs, and on Linux, using rpm or deb or other packaging
systems. Is there a technical reason why extension management cannot be
performed using those existing interfaces?
With Seamonkey, we already went through manager hell: profile manager,
download manager, personal security manager... somebody (Blake Ross?)
made this point by suggesting a brilliant Manager Manager. Let's avoid
this in Firefox if at all possible.
Robert Mohr wrote:
> And many other people bring up points in the thread you link to, but you don't attempt to refute their claims.
There's no reason to refute points that don't contradict mine, and to
yap for the sake of yapping. But since you ask:
- Boris (and later Gerv) said that JS Debugger and DOM Inspector can't
be unbundled; fine. That's not a compelling argument for an extension
manager UI.
- spaetz said that Winamp has lots of plug-ins, similar to extensions.
Winamp's plug-in manager UI, at a cursory glance, offers nothing
Add/Remove Programs doesn't offer.
- Gerv (and later Rob) said that distros will tend to bundle extensions,
that browser and mail should have entries in Add/Remove Programs.
- Imran said that, as a user, he wants to manage extensions. This
automatically places him in the class of power users (at best; at worst,
in the class of people conditioned by poor software design to demand
that they be given an illusion of control over their computers). Power
users' deep-seated extension management desires can be accomodated using
Add/Remove Programs.
None of those are compelling arguments for an extension manager UI.
-JT
Boris Zbarsky
> - Boris (and later Gerv) said that JS Debugger and DOM Inspector can't
> be unbundled
Or rather the small layout and JS engine (respectively) hooks cannot be
unbundled. Most of the apps themselves can be unbundled fine, as one
can see by te availability of JS Debugger upgrades in xpi form.
On the other hand, one thing that an extension manager would offer that
neither Add/Remove program nor rpm/deb offer is the ability to install
or uninstall extensions for _users_. rpm/deb both require root access
to install packages last I checked; certainly any options they have for
working with an alternate package database and alternate install
locations are not well known and not supported by the GUI front ends. I
would hope that Add/Remove has the same problem when running as a
non-Administrator user on Windows (if it doesn't, that's a scary
security setup).
-Boris
dmbtech
with the new linux installer? Is it still going to come out?
Laurens Holst
> - Imran said that, as a user, he wants to manage extensions. This
> automatically places him in the class of power users (at best; at worst,
> in the class of people conditioned by poor software design to demand
> that they be given an illusion of control over their computers). Power
> users' deep-seated extension management desires can be accomodated using
> Add/Remove Programs.
Well, responding from a user's point of view (somewhat 'power', I admit
:))...
The Windows Add/Remove programs manager is hidden away in configuration
panel, and from a Firefox-point-of-view not the first place I'd look for
the means to uninstall them. I always wonder why they never gave it a
more prominent place (though on the other hand, removing a program is
quite an invasive action so shouldn't be too easily accessible).
Anyways, I'm not exactly sure what is meant by this 'extension manager
UI', but it seems to me it is already there, add an uninstall button and
maybe an advanced options dialog or something... Anyways, whichever way
it will be done, I trust it will be done right. So far I really like the
Firefox settings UI (especially the to-the-point non-bloatedness of it).
Returning to add/remove programs... One thing about it (in Windows at
least) is that it is not threaded. In Firefox, one can easily install a
10-odd number of extensions to get cool extra features. Now the Window's
software deinstallation component is already a very unclear long list of
software (and MS adding their hotfixes to it only makes it longer - they
/really/ should have made it threaded). Imagine if those 10 extensions
would all be added to it, with their own names ofcourse, it would become
quite difficult to find them back again. Not to mention when say, I did
this on my father's computer, and he would go through the list to remove
unnessecary unused programs on his computer and he stubles upon all
those Firefox extensions. As they don't seem to be listed in Start Menu,
he discards them as leftovers or ad/spyware or whatever, and removes them.
Also, those extensions depend on Firefox. Add/remove presents them as
standalone things, and so what happens when you remove Firefox? It
removes 10 more entries in add/remove aswell? Kinda weird, if you ask
me. And what about the other things the extension manager UI does, it
doesn't uninstall alone I bet.
So, in the end it basically just comes down to (in my opinion) the
non-threadedness of the uninstaller list, and the way it fundamentally
works and is used. Oh, and the location, which is nowhere near Firefox
itself. In other words, an extension manager UI is just a thing to cope
with the fact that the OS does not offer anything better. Some people
have a similar view about tabs - 'why would you use it? bloat! the OS
has a taskbar for you!' would be a question you could ask. And they
would answer that it solves problems induced by a lack of functionality
in the OS, being that the taskbar gets so full very fast, and also that
it doesn't offer the user grouping options. I kind of agree.
Well, those were my thoughts on this :). *fantasizing about an ideal OS
now... ah, if only I could design one...* (it probably also would have
its issues *grin*).
Mooquackwooftweetmeow
> Just wondering, because i know you didn't mention it, whats going on
> with the new linux installer? Is it still going to come out?
Firefox roadmap (http://www.mozilla.org/projects/firefox/roadmap.html)
says 0.9.
Ben Goodger
> Remember http://tinyurl.com/38a7l? My apologies: I don't want to sound
> like a broken record, and I don't mean to say that Firefox developers
> should be beholden to the whims of J. Random Idiot User. But let me
> reiterate: why is there any need for an extension manager with its own UI?
>
> As you answer the question, consider two Windows UIs that are in the
> same genre: Control Panel's Add/Remove Programs, and Internet Explorer's
> Internet Options, Settings, View Objects. Behold the two attempts of a
> corporation with a huge usability testing organization at addressing the
> same problem, and tell me how useful and successful they are, and why we
> would expect Firefox's to be more useful and successful.
1) Add/Remove programs is for Windows applications
2) Internet Options, Settings, View Objects is for ActiveX controls
installed into Trident. .
3) You missed one - Windows XP SP2's new Add-on Manager in IE6.
None of these options are relevant to extensions written in XUL,
JavaScript, XPCOM components for a cross platform browser. Two of these
access points are buried within the competing application. None offer
all the functionality required of our extension manager:
- the ability to configure options for extensions in a single place
- the ability to perform update checking with a server (*)
- a system to resolve version and dependency conflicts
Your question about why we'd do our own UI is bogus. Why would we write
our own layout engine when there's Trident? We do what we do because of
an honest belief that what we produce is better than the competition. If
it weren't for that belief there'd be no point.
(* don't say WindowsUpdate)
-Ben
Ben Goodger
> Remember http://tinyurl.com/38a7l? My apologies: I don't want to sound
> like a broken record, and I don't mean to say that Firefox developers
> should be beholden to the whims of J. Random Idiot User. But let me
> reiterate: why is there any need for an extension manager with its own UI?
>
> As you answer the question, consider two Windows UIs that are in the
> same genre: Control Panel's Add/Remove Programs, and Internet Explorer's
> Internet Options, Settings, View Objects. Behold the two attempts of a
> corporation with a huge usability testing organization at addressing the
> same problem, and tell me how useful and successful they are, and why we
> would expect Firefox's to be more useful and successful.
1) Add/Remove programs is for Windows applications
Jack Tanner
> 1) Add/Remove programs is for Windows applications
> 2) Internet Options, Settings, View Objects is for ActiveX controls
> installed into Trident. .
> 3) You missed one - Windows XP SP2's new Add-on Manager in IE6.
>
> None of these options are relevant to extensions written in XUL,
> JavaScript, XPCOM components for a cross platform browser. Two of these
> access points are buried within the competing application. None offer
> all the functionality required of our extension manager:
I didn't mean that 1, 2 or 3 are what we should piggy-back onto, they're
merely examples of a UI with similar functionality. So unless the UI
Phoenix gets has different user-visible functionality, or unless the UI
Phoenix gets can be empirically better UI, there's no need to reinvent
the wheel in terms of what the UI looks like. For example, it could be
that the smart thing to do for configuring extensions on Windows would
be to open a Windows Explorer folder, just like IE does in 2, because
you'd at least expect users to be able to manage their files.
I grant you that I don't have good suggestions for cross-platform
problems, I'm not as familar with Gnome and KDE metaphors.
> - the ability to configure options for extensions in a single place
Add/Remove lets you configure options for whatever software is installed
there, and so does a Windows Explorer folder.
> - the ability to perform update checking with a server (*)
This doesn't need to be exposed in the UI. Just silently check for
updates, the way Seamonkey does now -- say, once a day when idle.
> - a system to resolve version and dependency conflicts
Again, this doesn't need to be exposed in the UI (or does it?).
> Your question about why we'd do our own UI is bogus. Why would we write
> our own layout engine when there's Trident? We do what we do because of
> an honest belief that what we produce is better than the competition. If
> it weren't for that belief there'd be no point.
Of course what we (you!) produce is better, I'm not disputing that. It
is because I hold the same belief that I'm bothering to contribute at
all. But that doesn't mean EVERY wheel must be reinvented.
Boris Zbarsky wrote:
> On the other hand, one thing that an extension manager would offer that neither Add/Remove program nor rpm/deb offer is the ability to install or uninstall extensions for _users_.
Now that is a good point. You want users to be able to install and
uninstall their own extensions, and you don't want one user to uninstall
the extensions of another (but you DO want to give an admin the ability
to prevent a user from installing extensions -- I guess you can do that
by globally disabling XPI install and write-protecting user.js).
I wonder if a per-user Windows Explorer folder would give us that
flexibility (and I wonder if this UI metaphor translates to Gnome and KDE).
-JT
Brendan Eich
>
> Now that is a good point. You want users to be able to install and
> uninstall their own extensions, and you don't want one user to uninstall
> the extensions of another (but you DO want to give an admin the ability
> to prevent a user from installing extensions -- I guess you can do that
> by globally disabling XPI install and write-protecting user.js).
This is all part of the plan Ben has documented and is implementing,
already.
> I wonder if a per-user Windows Explorer folder would give us that
> flexibility (and I wonder if this UI metaphor translates to Gnome and KDE).
What's a per-user Windows Explorer folder?
The plan is at http://www.mozilla.org/projects/firefox/extensions/ --
see http://www.mozilla.org/projects/firefox/extensions/structure.html in
particular.
/be
riscky
> Jack Tanner wrote:
>
>> Remember http://tinyurl.com/38a7l? My apologies: I don't want to sound
>> like a broken record, and I don't mean to say that Firefox developers
>> should be beholden to the whims of J. Random Idiot User. But let me
>> reiterate: why is there any need for an extension manager with its own
>> UI?
>>
>> As you answer the question, consider two Windows UIs that are in the
>> same genre: Control Panel's Add/Remove Programs, and Internet
>> Explorer's Internet Options, Settings, View Objects. Behold the two
>> attempts of a corporation with a huge usability testing organization
>> at addressing the same problem, and tell me how useful and successful
>> they are, and why we would expect Firefox's to be more useful and
>> successful.
>
>
> Your question about why we'd do our own UI is bogus. Why would we write
> our own layout engine when there's Trident? We do what we do because of
> an honest belief that what we produce is better than the competition. If
> it weren't for that belief there'd be no point.
>
> (* don't say WindowsUpdate)
>
> -Ben
I think Ben is touching on, but not including the biggest reason why Firefox (Thunderbird to) should
contain the notion of an Extension Manager. It just makes sense... think about how you install
extensions... think about how they are deployed... but beyond that an Extension Manager should do
more than install and remove an extension... it should be the UI for configuring the extension.
However, since you seem to be focused on Windows Add/Remove widget... I have this to ask... how
would you purpose that 'Extension X' informs (Windows word here registers) with all software
management schemes. What about systems that employ multiple schemes? What about systems that lack
the traditional software management schemes? Therefore, in this case it doesn't seem like a good
idea to reuse the wheel.
Not only does it seem bad to reuse the wheel... but I also don't think it would be wise to use the
axel. Firefox extensions are not "global" as Plug-ins, as in more than one program could use them...
nor are the "global" like a font... they are "local"... one and only one program uses them and lets
face it 99% of the time your going to install an extension via that program. Wouldn't it then make
since to allow the program that installed such an extension to remove it?
All that said I tend not to enjoy the conceptual idea of “managers” when it comes to many aspects of
daily computing... they just don’t mesh well with my desires or expectations... especially most
download managers, Firebird’s included.
Jack Tanner
> What's a per-user Windows Explorer folder?
A profile folder, as in every profile gets its own (which would
correspond to profile-specific extensions, per
http://www.mozilla.org/projects/firefox/extensions/structure.html). For
example, in IE, Internet Options, Settings, View Objects shows you a
folder of ActiveX objects, and lets you configure and uninstall them.
Now, think outside the box -- this is just a list of the objects, these
need not be the actual object files themselves, but the
folder-with-files metaphor works in this UI for configuring and
uninstalling.
Regardless, I think I'm being wildly misunderstood here. I am NOT trying
to say "Phoenix must not have an extension manager," although if we
could get by without one, I think we'd be better off. I AM trying to
say, "Phoenix's extension manager UI should not be different from
existing UIs that perform similar tasks unless there are some really
compelling reasons." To quote myself,
> So unless the UI Phoenix gets has different user-visible functionality, or unless the UI Phoenix gets can be empirically better UI, there's no need to reinvent the wheel in terms of what the UI looks like.
-JT