|Toolkit bootstrapping and startup||toolkit/xre, toolkit/library,
||Benjamin Smedberg||Darin Fisher|
|Toolkit general UI bits
||toolkit/content, toolkit/components (for
||Neil Deakin, Neil Rashbrook, Asaf Romano
||Benjamin Smedberg, Mike Connor, Ben Goodger
||toolkit/mozapps/installer (and later,
string approvals are ui-review fodder)
||Ben Goodger, Asaf Romano
||Mike Connor, Neil Deakin
||Ben Goodger, Benjamin Smedberg, Rob Strong
|GNOME Integration bits
||Darin Fisher, Neil Rashbrook
||Vladimir Vukicevic||Darin Fisher, Brett Wilson, Brian Ryner|
||Rob Strong, Darin Fisher|
Gnome is apparently moving. See
I didn't see autocomplete anywhere... It doesn't seem like a "Toolkit
general UI bit". Could it be lumped in with Satchel?
Man, you blink for a minute...
> I didn't see autocomplete anywhere... It doesn't seem like a "Toolkit
> general UI bit". Could it be lumped in with Satchel?
Hmm, perhaps, there's a lot of overlap between the two.
Either way is ok, as long as there's consistency
> toolkit/locales (build/packaging/policy stuff, string approvals are
> ui-review fodder)
> Benjamin Smedberg
> Axel Hecht
I'd rather have that the other way around, and I'm not sure what you
think is "ui-review fodder".
A note on the UI/app-specific pieces after some reflection:
I think "owner" is may not the best word for some pieces, specifically
the UI and stuff that's not designed to be part of the XRE. These pieces
were separated out of browser/ and mail/ and placed in toolkit/ for the
purpose of shared utility, and it was never Scott or my intent (I don't
believe, Scott can correct me if I'm wrong) that these pieces should be
For these pieces, I think a better word for those sections is
"reviewers" - especially since that meets the needs of the target
audience for these changes.
What do you think?
What pieces are you talking about in particular? We ship basically all of
toolkit/ as part of the XRE, except for the code in
toolkit/mozapps/installer. I don't unerstand the distinction being made.
From a pure architecture/hygiene point of view that doesn't seem like
the best idea.
IMO, inside toolkit/ XRE = application bootstrapping, XUL toolkit, core
There is other stuff in there like some of the stuff in mozapps/ -
shared pref panels, etc. Those shouldn't be part of XRE. That was my
argument for having mozapps be a toplevel dir back when it was created,
or at least cls' proposed:
mozilla/apps/shared <-- toolkit/mozapps
... plus some additional UI stuff in toolkit/content, like the customize
> IMO, inside toolkit/ XRE = application bootstrapping, XUL toolkit, core
> There is other stuff in there like some of the stuff in mozapps/ -
> shared pref panels, etc. Those shouldn't be part of XRE. That was my
> argument for having mozapps be a toplevel dir back when it was created,
> or at least cls' proposed:
I'm not sure about the shared pref panels: what are they and why aren't they
useful or potentially useful for non-mozilla apps? When making decisions
about whether code ought to be shipped in Firefox or XULRunner (code which
is going to be shipped in Firefox anyway, so it's a zero-sum game), my
strong preference is to err on the side of XULRunner.
> ... plus some additional UI stuff in toolkit/content, like the customize
> toolbars dialog.
This should absolutely be included in xulrunner: the functionality of
automatically-provided customizable toolbars is a major selling point of the
They're things like the downloads pref panel for Firefox/Thunderbird.
>> ... plus some additional UI stuff in toolkit/content, like the
>> customize toolbars dialog.
> This should absolutely be included in xulrunner: the functionality of
> automatically-provided customizable toolbars is a major selling point of
> the platform.
OK, but should the UI (which ships with Firefox and Thunderbird) be a
separate module developed independently of the other two? I don't think so.
What happens when FF/TB wishes to rework these shared UI elements in a
manner that breaks other XRE-consumers? I think our toolkit-derived
apps need a place to stick shared code that can be rapidly evolved w/o
concern for API stability. At the same time, API stability is a very
important goal of the XRE (or at least it should be), so we have a bit
of a conflict there.
> What happens when FF/TB wishes to rework these shared UI elements in a
> manner that breaks other XRE-consumers? I think our toolkit-derived
> apps need a place to stick shared code that can be rapidly evolved w/o
> concern for API stability. At the same time, API stability is a very
> important goal of the XRE (or at least it should be), so we have a bit
> of a conflict there.
How is reworking this UI different from other changes or non-UI changes?
Obviously we haven't frozen any system to launch the toolbar customization
1) we haven't defined an API for this at all! people include the JS file
and/or open the customizeToolbar dialog directly.
2) XUL itself isn't frozen
At some point we're going to want to define an API for launching the toolbar
customization code, but that doesn't mean we need to freeze the actual look
or behavior of the dialog.
The same rules apply for displaying the extension manager, the help viewer,
I think that we should treat this code the same way we treat
rapidly-evolving non-UI code: it's not frozen, we'll define and freeze APIs
for this when it stabilizes; in the meantime, use at your own risk.
Yes, mozapps to a big part sounds to me like something one should be
able to at least opt-out, better even only have in an opt-in model in a
Now that we are trying to get SeaMonkey working with toolkit, we saw for
example that some components are installed that other XULRunner apps
might not want - they might even want to not have EM turned on in their
app, same with the update service, the plugins stuff or helperAppDlg.
Or they may want to ship their own, different implementations of those,
and the mozapps components might clash with theirs.
We might want all or most of those in SeaMonkey (though we might want to
use different download manager chrome, for example) - for other,
non-Mozilla apps that might be different though.
Hmm, what about apps that are building with toolkit (MOZ_XUL_APP=1) but
aren't yet runninf fully on top of XULRunner (like SeaMonkey in the
What about other mozapps components than those two (in our case, EM is a
non-issue, should be enabled from the beginning and we also need some
profile migrator soon, either that one r something similar)?
Well, XULRunner just calls XRE_Main with configuration parameters
extracted from application.ini. So, you should be able to skip the
application.ini step, and just call XRE_Main with the configuration
parameters of your choosing.
Yes, but what about the other mozapps components - in either the
XULRunner or toolkit/XRE case there is no option (as I read
nsXULAppAPI.h) to disable Download Manager, which SeaMonkey currently
wants to do.
Are components in the application's directory guaranteed to override
I believe that on trunk this is true, making the assumption that nobody is
calling nsIComponentRegistrar.autoRegister manually (allowing the default
toolkit and xpcom autoregistration code follow its natural codepath).
This should also be true for chrome registration manifests. Both sets of
registrations should happen in the following order:
1. xulrunner (==GRE)
3. extensions (internal ordering of extension registration is unspecified)
4. other directories specified by custom directoryserviceproviders
ui-review is for approving the actual new/changed strings.
Given that bsmedberg is the person who implemented most (all?) of the
locale structure and packaging-fu, I think he's the appropriate owner.
That concept failed recently.
I definitely need to be in the loop of any of these. Not sure why you
would need an owner separately from that.
> Mike Connor wrote:
>> Axel Hecht wrote:
>>>> toolkit/locales (build/packaging/policy stuff, string
>>>> approvals are ui-review fodder)
>>>> Benjamin Smedberg
>>>> Axel Hecht
>>> I'd rather have that the other way around, and I'm not sure what
>>> you think is "ui-review fodder".
>> ui-review is for approving the actual new/changed strings.
>> Given that bsmedberg is the person who implemented most (all?) of
>> the locale structure and packaging-fu, I think he's the
>> appropriate owner.
> That concept failed recently.
What failed recently? Changes to strings themselves are for ui-
review, but the technical review should catch unchanged entities,
etc, if that's what you're talking about.
> I definitely need to be in the loop of any of these. Not sure why
> you would need an owner separately from that.
On any of what? String changes? I can make it so you see bugmail on
all ui-review requests, but this is about code ownership, not being-
in-the-loop. The structure and layout of how we build locales is
what bsmedberg would own, which isn't what you're really talking about.
What problem are you trying to solve?
As a little background, there's been some private discussion about rejigging the way we break down ownership of the various parts of toolkit. Ben asked me to take the detailed proposal public, so here goes:
Reviews getting to the right place often happens only because people are told who to ask by active community members. There is no obvious way to find out by yourself who is the best person to ask for review, or who to ask for help in figuring out where to fix a bug, etc. I believe in the principle of strong ownership, and with the size and breadth of toolkit its hard for any one person to be that owner. Breaking things up into sub-modules should mean that there's a clear advocate and strong hacker acting as a strong owner for all of the code we're relying on. The change in how we're defining members and how they gain responsibilities should help more people get involved and feel like they're being recognized, since its easier to establish a good track record with a smaller group before branching out.
This isn't absolutely necessary yet, with the current group of hackers, but I believe that adding the structure now will provide a better framework for adding new people to the group going forward. I want to create a clearer progression for new people getting involved in FE hacking (get involved, get responsibility for a small area and start helping with reviews, branch out into wider areas and eventually become a peer for the whole toolkit) which reflects the module peer->owner->superreviewer progression that seems to have worked for Gecko in many cases. It also allows people to not branch out, and just focus on the areas they're interested in working on, and still be given appropriate responsibility. Its a bit more of a benevolent feudal system than our traditional benevolent dictatorship, but I think its time to start building a larger hierarchy of people so there's more perceived room to fit in.
The more I look at how things are being done, and who is taking the leadership roles, I'd like to propose Benjamin Smedberg as the overall toolkit owner. Both on a technical level and with his focus on Mozilla-as-platform, he's obviously well-qualified, and he is doing the most to ensure that the toolkit is a strong platform. This also means that there's a check and balance between the needs of the apps, and the needs of other apps not reflected in the current structure (Songbird, Nvu, Sunbird, etc).
I also propose that Rob Strong should be elevated from member to peer, and Neil Deakin should be added as a peer.
Proposed Toolkit ownership structure (bold means changes in despot)
Toolkit Technical Lead: Benjamin Smedberg (listed as owner in despot)
UI Group: Ben Goodger, Mike Beltzner, Mike Connor
Peers (shown in despot): Vladimir Vukicevic, Scott MacGregor, Neil Rashbrook, Michael Connor, Brian Ryner, Darin Fisher, Ben Goodger, Robert Strong, Neil Deakin
Members: Asaf Romano, Masayuki Nagano, Brett Wilson
Toolkit bootstrapping and startup toolkit/xre, toolkit/library, toolkit/profile, toolkit/components/startup, toolkit/components/commandlines, toolkit/components/remote, toolkit/components/build
Benjamin Smedberg Darin Fisher Toolkit general UI bits
toolkit/content, toolkit/components (for those not covered elsewhere)
Neil Deakin, Neil Rashbrook, Asaf Romano
Benjamin Smedberg, Mike Connor, Ben Goodger
toolkit/mozapps/installer (and later, wherever NSIS lives)
toolkit/locales (build/packaging/policy stuff, string approvals are ui-review fodder)
Ben Goodger, Asaf Romano
Mike Connor, Neil Deakin
Ben Goodger, Benjamin Smedberg, Rob Strong
GNOME Integration bits
Darin Fisher, Neil Rashbrook
Vladimir Vukicevic Darin Fisher, Brett Wilson, Brian Ryner XULRunner
Rob Strong, Darin Fisher
Wherever possible, significant patches in a certain area should be reviewed by one of the listed sub-module owner/reviewers.
Peers may grant review in any area covered by toolkit, provided they feel confident in their knowledge of the code being changed.
One review is sufficient in most cases. If the first reviewer feels that the patch would benefit from additional reviews, they should request a second review from an appropriate person.
Members may only grant review in areas they are listed as reviewers (Author's note: this is to allow us to bring new people into certain areas without immediately giving them wide-ranging responsibility)
Significant UI changes should get UI review from someone in the UI group, along with code review.
Thoughts and feedback appreciated!
I'm talking about architecture questions here.
See https://bugzilla.mozilla.org/show_bug.cgi?id=320504 and
https://bugzilla.mozilla.org/show_bug.cgi?id=327465 for reference.
If we ever localize the uninstaller, this mistake is going to haunt us
again, I'm sadly sure about that.
That change did have bsmedberg's OK, and it broke the l10n checks he
And I was the one who had to fight for backing this stuff out, or at
least move it out of l10n, so as things stand, I own that part these days.
The other mishap like this was caught early (#ifdef MOZ_PLACES inside a
DTD) and got raised by a localizer to me and was handled by me (didn't
require more than a bug comment, but still).
>> I definitely need to be in the loop of any of these. Not sure why you
>> would need an owner separately from that.
> On any of what? String changes? I can make it so you see bugmail on all
> ui-review requests, but this is about code ownership, not
> being-in-the-loop. The structure and layout of how we build locales is
> what bsmedberg would own, which isn't what you're really talking about.
> What problem are you trying to solve?
Benjamin wrote the code, yes, but I'm not convinced that he wants to own
it these days.