This mainly comes out of our year-long history, but we should think
about updating the organization of those components once again.
Taking two bugs I remember I filed lately as example shows well what the
situation is atm:
When filing a bug to remove the old mork history code from toolkit/ (bug
383833), I naturally was looking for some "history" components first in
Toolkit, but nothing like that pops up. Then I looked through the quite
long list of the "Core" product, but no component there. Finally, I
ended up in Firefox/History with that bug.
For a bug about an openURL() in a central place in toolkit/ (bug 384139)
I once again didn't find anything matching in Toolkit and ended up with
Core/General as I could not find any specific component that would fit
Someone like me, who has been with the project for quite some time and
filed some 400 bugs, shouldn't feel as helpless as I did (and do again
and again) when looking for the right product (!) and component to file
such bugs in.
Three major current problems come to my mind there:
1) The biggest problem is probably the unclear definition of what is
tracked in Core and what in Toolkit.
2) Additionally, we have components like history and places in Firefox
when the code is in Toolkit
3) Then, the Core product looks just too huge for me, with too much more
or less unrelated components thrown into it.
I'm not sure myself how it ideally should look in the future, but we
should address the three problems above. Just some thoughts that I have
in my head about this currently:
- Move the components about toolkit/ code that are in Firefox over to
- maybe split shared MailNews components currently in Core into a
separate product, this could also be some "shared application code" or
such with a description telling that those are not parts of XULrunner
but shared between several apps. There may be a possibility to merge
that into the "other apps" product.
- make description of Core even clearer, maybe get it trimmed to to
"just Gecko" (whatever exactly Gecko means in those terms)
- get at least everything into Toolkit that actually has its code in
toolkit/ in the tree
Those steps/thoughts might be inconclusive and I'm just a contributor, I
can't decide on those structures anyways - I'd like to get a discussion
going though that improves all our lives with the mozilla.org Bugzilla.
Note that history UI should be in Firefox, while history backend should be in
> Someone like me, who has been with the project for quite some time and
> filed some 400 bugs, shouldn't feel as helpless as I did (and do again
> and again) when looking for the right product (!) and component to file
> such bugs in.
Amen. I end up having to ask on IRC pretty much any time I want to file a
> Three major current problems come to my mind there:
> 1) The biggest problem is probably the unclear definition of what is
> tracked in Core and what in Toolkit.
Agreed. This is a silly dichotomy and we ought to remove it. I would favor
folding all the toolkit components back into Core, or merging both "Core"
and "Toolkit" into a single "Platform" product.
> 3) Then, the Core product looks just too huge for me, with too much more
> or less unrelated components thrown into it.
Also agreed. I think that we have too much taxonomy, which makes
categorizing and finding bugs harder, not easier. In general I think the
bugzilla components should be as grouped by "the people who need to see
reports about this thing" and should be fairly broad.
But, the hard part of this discussion has never been the "what should we do"
but "how do we do it"... it will almost certainly involve custom SQL queries
to move componnets and bugs around, rather than mass changes.
>I'm not sure myself how it ideally should look in the future, but we
>should address the three problems above. Just some thoughts that I have
>in my head about this currently:
>- Move the components about toolkit/ code that are in Firefox over to
Yes. That goes for
- Firefox -> Error Console
- Firefox -> Extension/Theme Manager
- Firefox -> Software Update
- Firefox -> Startup and Profile System
The following components alos have their code in toolkit, but since all
non-browsing apps probably do not use them (at least Sunbird doesn't),
it's probably not a good idea, to move them away from Firefox, where most
of the bugs are reported and need to be triaged.
- Firefox -> Download Manager
- Fireofx -> Plugin Finder Service
Well, the scripts for resolving that sort of thing are surely blocking
other areas than the Core/Toolkit/Platform thing mentioned here as well,
like https://bugzilla.mozilla.org/show_bug.cgi?id=298904 (SeaMonkey
Bugzilla product restructuring).
Still, if the script is needed in more places, we probably have more
chance that someone will finish writing it up, as it might increase in
priority. The problem there is probably that justdave and reed don't
have enough time to work on it but apparently nobody else has the
knowledge to do that work.
Not necessarily; both ways have advantages and disadvantages.
But it is true to say that the "how" need not be discussed here. I've
started another email thread to work that out. Without wanting to
promise anything, let's focus on the "what" - because nothing will ever
happen without a clear plan.
OK. Here's the plan. I have created:
which shows the current state of b.m.o., together with a proposed future
state (currently identical to the current state). It's organised as a
tree, with Classification, Product and Component levels, and you can
expand and contract the tree.
In this thread, people should propose (or re-propose) a change, and we
can discuss it. Each change or related set of changes should be proposed
in a new post, containing no other commentary. Prefix the title with
"Proposal:" and then a summary of the change.
Each one can then be discussed. If we feel it's right, I'll update the
"Proposed" organisation on the right hand side of that page. Once
discussion has settled down, we can think about implementing it.
This effort will probably need to be publicised further afield than this
newsgroup at some point soon, but let's just start with what we have.
I disagree with this, just because other apps don't use them now (does
Seamonkey not?) doesn't mean they won't in the future. If the code is
not part of browser/ then I don't think it's component should be under
Firefox. It may make it more difficult for new reporters to find the
right component, but if random core components are in proucts then we
make life difficult for triagers too.
What is the difference between:
# XP Toolkit/Widgets
# XP Toolkit/Widgets: Menus
# XP Toolkit/Widgets: Trees
# XP Toolkit/Widgets: XUL
# XUL Widgets
I'm wondering if these could/should be consolidated.
Indeed. IMHO a component shared (with identical code) between Firefox and
SeaMonkey ought to be listed under neither, but under some "shared" product
like Core, Toolkit, etc. Otherwise I expect that:
- SeaMonkey users (those significantly less savvy than KaiRo) won't be able to
find them under Firefox;
- or if they do, someone (not necessarily someone very enlightened) is bound
to tell them "Don't spam this Firefox bug with **** complaints about SeaMonkey!".
If the code is _not_ identical (such that bugs in that component could
conceivably bite one product but not the other), then I suppose it would be
better to have parallel components under both products (as for, perhaps, the
Tabbed Browser component, which IIUC differs significantly between Firefox 2
and SeaMonkey 1.1). Otherwise, where do I file a tabbed-browser bug which
(like at least one that I've seen) affects suiterunner but not Minefield, or
Sm1.1 but not BonEcho?
But, to make life easier for triagers and reporters alike:
a) Would it be possible to have "redirecting" components in Bugzilla (if not
in this version, then in some future version)? I mean, a bug could be "filed"
under Firefox => Download Manager in the guided form; but once submitted it
would automagically find itself under (let's say) Toolkit => Download Manager.
b) If a) is not feasible, it would certainly be possible to define (let's say)
a "dummy" Firefox => Download Manager component, with the following
Description (or something similar):
This component has been moved. Please file bugs for the Firefox download
manager under the <a href=...>Toolkit</a> product.
DINGO: And after the spanking ... the oral sex.
GALAHAD: Oh, dear! Well, I...
GIRLS: The oral sex ... The oral sex.
GALAHAD: Well, I suppose I could stay a BIT longer.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
IIUC, it is shared (with identical or almost-identical code) between (at
least) Firefox (since 1.0 or maybe earlier), Thunderbird (since 1.0 or maybe
earlier) and SeaMonkey (since 2.0a1pre). So it should (IMHO) indeed be in some
"shared" component, either Toolkit if it is kept, Core if Toolkit and Core are
"Honesty is the best policy, but insanity is a better defense"
So I propose to move Error Console to Toolkit. Thunderbird uses the same
thing, and the code is in mozilla/toolkit/components/console.
XP Toolkit/Widgets: Menus
XP Toolkit/Widgets: Trees
XP Toolkit/Widgets: XUL
Into simply "XUL"
We could possibly add "Layout: XUL" too to cover the layout parts.
We could possibly add "XUL: Trees" and "XUL: Templates" too, but I'm not
sure they'd get enough bugs to warrent their own categories.
has been alive in a long time, right?
IIUC XP Toolkit is "/xpfe"
Where "Toolkit" # "XUL Widgets" is "/toolkit" stuff
the xpfe stuff is no longer used (majority anyway) by SeaMonkey, and a
LARGE portion of the codebase.
It might not be ready to be removed yet, but soon, maybe.
~Justin Wood (Callek)
(Not an authority, but figured I'd offer what I recall)
Qt and Xlib have been removed.
We'd try and make sure that didn't happen this time.
With the new name being "Startup and Profile System"?
Where do the bugs go? Do you want to obsolete the component, or merge it
into another one?
We can't actually remove products or components without finding a home
for the bugs.
I suggest we have a new product (closed to bug entry, like Mozilla
Classic). If the merge of Core and Toolkit ends up being called
"Platform", it could be called something like "Platform (Obsolete)". We
can put components like Xprint, XPFE-related components, dead ports,
dead widgets etc. in there.
These components are in Core. How do they fit with Toolkit/XUL Widgets?
Are these ones relating to XPFE? If so, should they not just be obsoleted?
FWIW, I've seen people use Toolkit/XUL and Core/XUL interchangeably.
The distinction has never been made clear.
Putting all XUL bugs (bugs in toolkit XBL bindings, in
content/xul/document, content/xul/content, the template builder, and
layout) in a single component will make this component rather large; I
don't think it's a good idea.
Yes the app provides no real EM code (other than a menu option to open
it) so assuming they are from the same CVS branch then they are the
same. I could also reel off Sunbird, Songbird, Nvu and Komodo as other
Photon has done a release of every major version so far, so I'd say it's not
dead... the others are quite dead.
> On 6/14/07, Gervase Markham <ge...@mozilla.org> wrote:
> FWIW, I've seen people use Toolkit/XUL and Core/XUL interchangeably.
> The distinction has never been made clear.
> Putting all XUL bugs (bugs in toolkit XBL bindings, in
> content/xul/document, content/xul/content, the template builder, and
> layout) in a single component will make this component rather large; I
> don't think it's a good idea.
Agreed. I think there's a clear difference at least between the XUL
layout/content pieces and the stuff in toolkit/content/widgets, and
these should remain separate.
Bug 271978 is a bug which lists a few proposals like this one. It
should probably be closed after this reorganization.
Ideally, someone connected with that bug would come and propose the
changes here, for equal discussion with everything else.
I'm fully with you. And while SeaMonkey is not using those yet, we're
planning and working hard on doing so in the future.
From what I understood, the Core XUL components are for code in layout/xul --
the C++ XUL implementation (and probably XUL-related layout/base and
layout/generic code). The toolkit XUL component is for code in
toolkit/content/widgets/ -- the XBL bindings implementing various UI widgets.
There is _some_ overlap between the people working on the two, and it's been
growing. So we might be able to just have a single XUL component now.
> Are these ones relating to XPFE?
It used to be, yes. In the past we've changed the meaning of components without
moving the old bugs out of them....
It may be a good idea to get the planned SeaMonkey structure of
https://bugzilla.mozilla.org/show_bug.cgi?id=298904 in that graph, but I
don't think we need a thread to specifically discuss that here, as the
structure is decided, it just hasn't been done yet.
IIRC, it is obsolete already, it should move into a closed obsolete
product like you proposed in the xprint subthread.
Right. But XUL it may be a good idea to merge all XUL widgets in
toolkit/ to be tracked in one single component under the Toolkit product.
Fair enough - it's your product :-) Some questions:
- I agree almost entirely with your choice of new names but, from an
aesthetic point of view, Do you really need the "Browsing tools:"
prefix? I think it's ugly, and it means that View Source is filed under
"B", as is "Page Info" - when I would look for them normally under V and
- Should "UI design" be "UI Design", for consistency?
- Should "ViewSource" be "View Source", for consistency with the other
component of that name?
If that's true, then instead of altering our hierarchy to fix the
problem, we need to make Bugzilla capable of displaying the components
from more than one Product at once - either by Mozilla-specific
customisation (could be done) or more generally.
There are ten open bugs in it. Are these to be abandoned? If not, they
need a new component to live in. And if they are having a new component,
they might as well be followed by all the closed ones as well.
>I filed bug 271978 back in 2004 already: "move several components from
>Firefox to Toolkit". From that list, only Help Viewer got moved to
>Toolkit; the bugs lost their flags (review?, review+ etc.) and target
>milestones in the process. But that might be better now that Toolkit
>doesn't use first-review anymore.
>So I propose to move Error Console to Toolkit. Thunderbird uses the same
>thing, and the code is in mozilla/toolkit/components/console.
Sunbird is also a user of this component.
>Let's move Software Update from Firefox to toolkit. It's used by
>Thunderbird as well.
... as well as (IIUC) SeaMonkey 2.0a1pre "and later" (currently trunk only,
and very alpha, but that's the going trend).
Sits at the keyboard
And waits for a line on the screen
Lives in a dream
Waits for a signal
Finding some code
That will make the machine do some more.
What is it for?
All the lonely users, where do they all come from?
All the lonely users, why does it take so long?
Still, its description includes "COMPONENT RETIRED. Please do not file
So the component itself should move to some obsolete place, I'd guess,
if one is created. If there are misfiled bugs in it, they should be
sorted out to a better place.
OK, maybe that's overdoing it. The thought was to get browser-specific
parts grouped like the mailnews ones, but maybe that's overdoing it a bit.
In this case, the autocomplete component should also be just "Autocomplete".
> - Should "UI design" be "UI Design", for consistency?
Yes, good idea.
> - Should "ViewSource" be "View Source", for consistency with the other
> component of that name?
I think so. The current old name is "ViewSource" but I think two words
are better there. We might even retire the old xpfe view source in favor
of toolkit's with an overlay or so, but that's not done yet, so the
component is probably still right.
A few small changes to the list came up when I thought about it once
more from a current point of view and cleared even more things up (I'll
note those on the bug as well):
- Instead of creating a new SeaMonkey::Themes component, Core::Themes
should move into SeaMonkey and get the desc, etc. we have in the
SeaMonkey list. The current component in Core does only track
SeaMonkey's default and Modern themes, actually.
- Core::Search is also suite only and should move to the SeaMonkey product.
- Core::Location Bar is another such case, move it.
- same with Core::Tabbed Browser
- We might want to rename Bookmarks to "Bookmarks and History",
including history UI in preparation of using places backends, but I got
to discuss that with other SeaMonkey people first.
- I got to rediscuss with MailNews folks about which MailNews components
really belong to SeaMonkey and which to a shared product.
- Cmd-line Features
obsolete, SeaMonkey-only or still Core?
- Embedding: GRE Core
- Embedding: Packaging
- History: Global
apparently mostly the almost-obsolete XPFE history backend. UI bugs
should be moved to the appropriate SeaMonkey component manually, I guess
- Installer: XPInstall Engine
If this is app installers based on it, it's probably obsolete. If it
includes .xpi install, it's live and correct in Core.
- Keyboard: Find as you Type
might be SeaMonkey
- Keyboard: Navigation
might be SeaMonkey-related but shouldn't be a separate component itself,
bugs should go into components fitting for the respective UI
- Print Preview
it that's XPFE, then it's probably obsolete
- Profile: BackEnd
- Profile: Migration
it that's XPFE, then it's probably obsolete
Absolutely. The categories listed above are all in Core and the "XUL
Widgets" in Toolkit should remain as is.
I think we should move those either to the "Other Applications" product
or create a new MailNews product for that shared code.
All of the Core::Mailnews:* components are affected by that, we should
look into what parts of SeaMonkey's MailNews:* may be affected and which
parts of Thunderbird may be affected.
We need heavy input from actual (SeaMonkey and Thunderbird) MailNews
A lot of core mailnews bugs will still get filed against Thunderbird,
but a top level product would help some, and it would help make the Core
product easier to use.
The name switched in the code partially to differentiate it from the old
implementation, and partly because it's a more accurate representation
of what it does.
If you think we should keep it in Bugzilla as "Password Manager" for
now, that's fine. I presume that renaming it in the future, if we decide
to, if trivial compared to moving it to a new product.
I don't see how that would help with anything, but actually I'm as fine
with those location as I am with Core.
Feel free to correct my English. :)
I'm under the assumption (or allusion) that "XRE Startup" is *not* the
same as "Toolkit Startup" and really, unless *any* mozilla app now uses
xpfe/ code for startup/profile then the component is really outdated and
need not be migrated anywhere (SeaMonkey no longer uses xpfe/ for startup)
If my assumption is incorrect (and really, even if it is) I'm ok with
new name as "Startup and Profile System"
~Justin Wood (Callek)
~Justin Wood (Callek)
XRE is the toolkit startup system, and is quite alive. I think you're mixing
up "xre" and "xpfe".
Yep, must be, thanks for clarifying that for me.
~Justin Wood (Callek)
For this I think you could actually move the existing bugs to
Core:General and remove the component entierly.
This was used by the installers, but is still used by the apps to
install .xpi files.
> - Print Preview
> it that's XPFE, then it's probably obsolete
This probably has SeaMonkey UI + backend bugs, probably mostly backend.
Some of the backend bugs might end up in a new Layout->Printing
component. Firefox has it's own printing component for the UI (toolkit
mostly, I guess).