Organization of Core and Toolkit products in Bugzilla

9 views
Skip to first unread message

Robert Kaiser

unread,
Jun 12, 2007, 2:30:02 PM6/12/07
to
Lately, I've bee filing a few bugs in code that is part of XULRunner and
was searching bugs in that code, and I found that the current Bugzilla
components are a bit of a mess around that.

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
for me.
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
Toolkit
- 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.

Robert Kaiser

Boris Zbarsky

unread,
Jun 12, 2007, 2:36:40 PM6/12/07
to
Robert Kaiser wrote:
> 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.

Note that history UI should be in Firefox, while history backend should be in
Toolkit. Probably...

> 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
non-Core bug.

-Boris

Benjamin Smedberg

unread,
Jun 12, 2007, 2:46:30 PM6/12/07
to
Robert Kaiser wrote:

> 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.

--BDS

Simon Paquet

unread,
Jun 12, 2007, 8:02:22 PM6/12/07
to
And on the seventh day Robert Kaiser spoke:

>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
>Toolkit

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

Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar

Robert Kaiser

unread,
Jun 13, 2007, 6:36:13 AM6/13/07
to
Benjamin Smedberg schrieb:

> 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.

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.

Robert Kaiser

Gervase Markham

unread,
Jun 13, 2007, 7:26:56 AM6/13/07
to
Benjamin Smedberg wrote:
> 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.

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.

Gerv

Gervase Markham

unread,
Jun 13, 2007, 7:30:33 AM6/13/07
to
Robert Kaiser wrote:
> This mainly comes out of our year-long history, but we should think
> about updating the organization of those components once again.

OK. Here's the plan. I have created:
http://www.gerv.net/temp/bmo-reorg.html
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.

Gerv

Gervase Markham

unread,
Jun 13, 2007, 7:33:37 AM6/13/07
to
The Grendel code has been CVS-removed. I suggest we move that Bugzilla
product to the Unclassified classification and make it impossible for
people to enter bugs in it (i.e. just like MozillaClassic and Derivatives).

Gerv

Dave Townsend

unread,
Jun 13, 2007, 7:35:06 AM6/13/07
to
Simon Paquet wrote:
> 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

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.

Dave Townsend

unread,
Jun 13, 2007, 8:10:32 AM6/13/07
to
The Extension Manager is in use by I believe the majority of
applications now and I have seen Thunderbird users confused as to why
their bugs have ended up in Firefox. Firefox is clearly not the place
for this component so it should either be moved to Toolkit, or should
Toolkit be done away with then to wherever all the other current Toolkit
comonents go.

B. Polidoro

unread,
Jun 13, 2007, 10:49:34 AM6/13/07
to

What is the difference between:
Core
# XP Toolkit/Widgets
# XP Toolkit/Widgets: Menus
# XP Toolkit/Widgets: Trees
# XP Toolkit/Widgets: XUL

And
Toolkit
# XUL Widgets

I'm wondering if these could/should be consolidated.

Brian Polidoro

Tony Mechelynck

unread,
Jun 13, 2007, 10:54:17 AM6/13/07
to

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.


Best regards,
Tony.
--
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

Tony Mechelynck

unread,
Jun 13, 2007, 11:01:24 AM6/13/07
to

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
merged, etc.


Best regards,
Tony.
--
"Honesty is the best policy, but insanity is a better defense"

Steffen Wilberg

unread,
Jun 13, 2007, 6:16:03 PM6/13/07
to
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.

Steffen

Steffen Wilberg

unread,
Jun 13, 2007, 6:17:38 PM6/13/07
to
Let's move View Source to toolkit.
mozilla/toolkit/components/viewsource/

Steffen Wilberg

unread,
Jun 13, 2007, 6:19:03 PM6/13/07
to
Let's move "Startup and Profile System" to toolkit, and merge it with
"XRE Startup".
mozilla/toolkit/profile/

Steffen Wilberg

unread,
Jun 13, 2007, 6:21:58 PM6/13/07
to
Let's move Download Manager to toolkit. Even Thunderbird displays
sometimes it when downloading large attachments. Seamonkey uses it as
well or will do so soon.
mozilla/toolkit/mozapps/downloads/

Steffen Wilberg

unread,
Jun 13, 2007, 6:23:37 PM6/13/07
to
Let's move Software Update from Firefox to toolkit. It's used by
Thunderbird as well.
mozilla/toolkit/mozapps/update/

Jonas Sicking

unread,
Jun 13, 2007, 8:36:53 PM6/13/07
to
Xprint was just removed from the tree so lets kill it here too.

/ Jonas

Jonas Sicking

unread,
Jun 13, 2007, 8:38:22 PM6/13/07
to
WTF is XP Miscellany? Lets get rid of it, there are other catch-all
categories.

/ Jonas

Jonas Sicking

unread,
Jun 13, 2007, 8:43:47 PM6/13/07
to
Let's merge

XP Toolkit/Widgets
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.

/ Jonas

Jonas Sicking

unread,
Jun 13, 2007, 8:49:40 PM6/13/07
to
None of

Ports: Qt
Widget: Photon
Widget: Xlib

has been alive in a long time, right?

/ Jonas

Justin Wood (Callek)

unread,
Jun 13, 2007, 9:16:09 PM6/13/07
to

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)

Mats Palmgren

unread,
Jun 13, 2007, 11:19:45 PM6/13/07
to Jonas Sicking


Regarding Photon:
https://bugzilla.mozilla.org/show_bug.cgi?id=376791#c4

Qt and Xlib have been removed.


/Mats

Gervase Markham

unread,
Jun 14, 2007, 3:40:45 AM6/14/07
to
Steffen Wilberg wrote:
> 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.

We'd try and make sure that didn't happen this time.

Gerv

Gervase Markham

unread,
Jun 14, 2007, 3:44:15 AM6/14/07
to

With the new name being "Startup and Profile System"?

Gerv

Gervase Markham

unread,
Jun 14, 2007, 3:46:47 AM6/14/07
to
Jonas Sicking wrote:
> WTF is XP Miscellany? Lets get rid of it, there are other catch-all
> categories.

Where do the bugs go? Do you want to obsolete the component, or merge it
into another one?

Gerv

Gervase Markham

unread,
Jun 14, 2007, 3:47:33 AM6/14/07
to
Jonas Sicking wrote:
> Xprint was just removed from the tree so lets kill it here too.

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.

Gerv

Gervase Markham

unread,
Jun 14, 2007, 3:49:21 AM6/14/07
to
Jonas Sicking wrote:
> Let's merge
>
> XP Toolkit/Widgets
> XP Toolkit/Widgets: Menus
> XP Toolkit/Widgets: Trees
> XP Toolkit/Widgets: XUL
>
> Into simply "XUL"

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?

Gerv

Nickolay Ponomarev

unread,
Jun 14, 2007, 4:13:16 AM6/14/07
to dev-pl...@lists.mozilla.org

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.

Nickolay

Justin Dolske

unread,
Jun 14, 2007, 4:43:15 AM6/14/07
to
The code has lived in toolkit/components/ for a long time, so this is
mostly a no-brainer.

Mmm. Braaaaaains.

Justin

Dave Townsend

unread,
Jun 14, 2007, 5:14:16 AM6/14/07
to
Tony Mechelynck wrote:
> 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).

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
users.

Benjamin Smedberg

unread,
Jun 14, 2007, 6:24:41 AM6/14/07
to
Jonas Sicking wrote:
> None of
>
> Ports: Qt
> Widget: Photon
> Widget: Xlib

Photon has done a release of every major version so far, so I'd say it's not
dead... the others are quite dead.

--BDS

Mike Connor

unread,
Jun 14, 2007, 9:09:57 AM6/14/07
to Nickolay Ponomarev, dev-pl...@lists.mozilla.org

On 14-Jun-07, at 4:13 AM, Nickolay Ponomarev wrote:

> 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.

-- MIke

Alex Vincent

unread,
Jun 14, 2007, 9:21:46 AM6/14/07
to

Alex Vincent

unread,
Jun 14, 2007, 9:27:45 AM6/14/07
to
Robert Kaiser wrote:
> Lately, I've bee filing a few bugs in code that is part of XULRunner and
> was searching bugs in that code, and I found that the current Bugzilla
> components are a bit of a mess around that.

Bug 271978 is a bug which lists a few proposals like this one. It
should probably be closed after this reorganization.

Gervase Markham

unread,
Jun 14, 2007, 10:57:31 AM6/14/07
to
Alex Vincent wrote:
> 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.

Gerv

Mike Beltzner

unread,
Jun 14, 2007, 11:15:00 AM6/14/07
to Justin Dolske, dev-pl...@lists.mozilla.org
Any reason for the name switch? I don't know if I'd look for it under the name "Login Manager" if the feature is called "Password Manager", but I'm pretty literal that way ;)

cheers,
mike

Mmm. Braaaaaains.

Justin
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

Robert Kaiser

unread,
Jun 14, 2007, 12:11:30 PM6/14/07
to
Dave Townsend schrieb:
> Simon Paquet wrote:
>> 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
>
> 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.

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.

Robert Kaiser

Boris Zbarsky

unread,
Jun 14, 2007, 12:13:13 PM6/14/07
to
Gervase Markham wrote:
> These components are in Core. How do they fit with Toolkit/XUL Widgets?

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....

-Boris

Robert Kaiser

unread,
Jun 14, 2007, 12:15:04 PM6/14/07
to
Gervase Markham schrieb:

> OK. Here's the plan. I have created:
> http://www.gerv.net/temp/bmo-reorg.html
> 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.

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.

Robert Kaiser

Robert Kaiser

unread,
Jun 14, 2007, 12:18:15 PM6/14/07
to
Gervase Markham schrieb:

IIRC, it is obsolete already, it should move into a closed obsolete
product like you proposed in the xprint subthread.

Robert Kaiser

Robert Kaiser

unread,
Jun 14, 2007, 12:20:25 PM6/14/07
to
Mike Connor schrieb:

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.

Robert Kaiser

Gervase Markham

unread,
Jun 14, 2007, 12:47:33 PM6/14/07
to
Robert Kaiser wrote:
> 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.

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
P respectively.

- Should "UI design" be "UI Design", for consistency?

- Should "ViewSource" be "View Source", for consistency with the other
component of that name?

Gerv

Mike Connor

unread,
Jun 14, 2007, 12:46:55 PM6/14/07
to dev-pl...@lists.mozilla.org
Like Toolkit: XUL Widgets? :)

- Mike

-----Original Message-----
From: Robert Kaiser <ka...@kairo.at>

Date: Thu, 14 Jun 2007 18:20:25
To:dev-pl...@lists.mozilla.org
Subject: Re: Proposal: Have proper XUL categories

Gervase Markham

unread,
Jun 14, 2007, 12:59:33 PM6/14/07
to
Dave Townsend wrote:
> It may make it more difficult for new reporters to find the
> right component

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.

Gerv

Gervase Markham

unread,
Jun 14, 2007, 1:02:22 PM6/14/07
to
Robert Kaiser wrote:
> IIRC, it is obsolete already, it should move into a closed obsolete
> product like you proposed in the xprint subthread.

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.

Gerv

Nickolay Ponomarev

unread,
Jun 14, 2007, 1:29:41 PM6/14/07
to Gervase Markham, dev-pl...@lists.mozilla.org
On 6/14/07, Gervase Markham <ge...@mozilla.org> wrote:
Most are either old or misfiled and can as well be in Core:General. Is
moving all the (closed) bugs to an existing component better in any
way than abandoning the whole component?

Nickolay

Simon Paquet

unread,
Jun 14, 2007, 2:26:04 PM6/14/07
to
And on the seventh day Steffen Wilberg spoke:

>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.

Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar

Simon Paquet

unread,
Jun 14, 2007, 2:26:31 PM6/14/07
to
And on the seventh day Steffen Wilberg spoke:

>Let's move Software Update from Firefox to toolkit. It's used by
>Thunderbird as well.
>mozilla/toolkit/mozapps/update/

Tony Mechelynck

unread,
Jun 14, 2007, 3:06:01 PM6/14/07
to
Simon Paquet wrote:
> And on the seventh day Steffen Wilberg spoke:
>
>> Let's move Software Update from Firefox to toolkit. It's used by
>> Thunderbird as well.
>> mozilla/toolkit/mozapps/update/
>
> Sunbird is also a user of this component.
>
> Simon

... as well as (IIUC) SeaMonkey 2.0a1pre "and later" (currently trunk only,
and very alpha, but that's the going trend).


Best regards,
Tony.
--
Eleanor Rigby
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?

Robert Kaiser

unread,
Jun 14, 2007, 3:17:36 PM6/14/07
to
Gervase Markham schrieb:

Still, its description includes "COMPONENT RETIRED. Please do not file
bugs here."

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.

Robert Kaiser

Robert Kaiser

unread,
Jun 14, 2007, 4:48:41 PM6/14/07
to
Gervase Markham schrieb:

> - 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
> P respectively.

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.


Robert Kaiser

Robert Kaiser

unread,
Jun 14, 2007, 4:51:25 PM6/14/07
to
Decided to split those off of the "obsolete" proposal, as those Core
components are still unclear to me:

- Cmd-line Features
obsolete, SeaMonkey-only or still Core?

- Embedding: GRE Core
- Embedding: Packaging
obsolete?

- 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

Robert Kaiser

Jonas Sicking

unread,
Jun 14, 2007, 4:59:58 PM6/14/07
to

Absolutely. The categories listed above are all in Core and the "XUL
Widgets" in Toolkit should remain as is.

/ Jonas

Robert Kaiser

unread,
Jun 14, 2007, 5:01:50 PM6/14/07
to
For what I see, Core is currently too huge and MailNews takes up a
significant portion of it.

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
people there.

Robert Kaiser

David Bienvenu

unread,
Jun 14, 2007, 5:37:45 PM6/14/07
to
Robert Kaiser wrote:
> For what I see, Core is currently too huge and MailNews takes up a
> significant portion of it.
>
> I think we should move those either to the "Other Applications"
> product or create a new MailNews product for that shared code.
It would be a lot easier if there were a top level product, MailNews
Core or MailNews backend, or something like that, with most or all of
the existing mail components, including the networking | imap/nntp/pop3
etc components.

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.

- David

Justin Dolske

unread,
Jun 14, 2007, 5:44:52 PM6/14/07
to
Mike Beltzner wrote:
> Any reason for the name switch? I don't know if I'd look for it under the name "Login Manager" if the feature is called "Password Manager", but I'm pretty literal that way ;)

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.

Justin

Karsten Düsterloh

unread,
Jun 14, 2007, 6:00:04 PM6/14/07
to
Robert Kaiser aber hob zu reden an und schrieb:

> For what I see, Core is currently too huge and MailNews takes up a
> significant portion of it.
>
> I think we should move those either to the "Other Applications" product
> or create a new MailNews product for that shared code.

I don't see how that would help with anything, but actually I'm as fine
with those location as I am with Core.


Karsten
--
Feel free to correct my English. :)

Justin Wood (Callek)

unread,
Jun 14, 2007, 6:15:06 PM6/14/07
to
Gervase Markham wrote:
> Steffen Wilberg wrote:
>> Let's move "Startup and Profile System" to toolkit, and merge it with
>> "XRE Startup".
>> mozilla/toolkit/profile/
>
> With the new name being "Startup and Profile System"?
>
> Gerv

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)

unread,
Jun 14, 2007, 6:22:22 PM6/14/07
to

agreed, heavily.

~Justin Wood (Callek)

Benjamin Smedberg

unread,
Jun 14, 2007, 6:40:50 PM6/14/07
to
Justin Wood (Callek) wrote:
> Gervase Markham wrote:
>> Steffen Wilberg wrote:
>>> Let's move "Startup and Profile System" to toolkit, and merge it with
>>> "XRE Startup".
>>> mozilla/toolkit/profile/
>>
>> With the new name being "Startup and Profile System"?
>>
>> Gerv
>
> 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)

XRE is the toolkit startup system, and is quite alive. I think you're mixing
up "xre" and "xpfe".

--BDS

Justin Wood (Callek)

unread,
Jun 14, 2007, 6:43:08 PM6/14/07
to
Benjamin Smedberg wrote:
> Justin Wood (Callek) wrote:
>> Gervase Markham wrote:
>>> Steffen Wilberg wrote:
>>>> Let's move "Startup and Profile System" to toolkit, and merge it with
>>>> "XRE Startup".
>>>> mozilla/toolkit/profile/
>>> With the new name being "Startup and Profile System"?
>>>
>>> Gerv
>> 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)
>
> XRE is the toolkit startup system, ... I think you're mixing

> up "xre" and "xpfe".

Yep, must be, thanks for clarifying that for me.

~Justin Wood (Callek)

Jonas Sicking

unread,
Jun 14, 2007, 8:27:15 PM6/14/07
to
Gervase Markham wrote:
> Jonas Sicking wrote:
>> WTF is XP Miscellany? Lets get rid of it, there are other catch-all
>> categories.
>
> Where do the bugs go? Do you want to obsolete the component, or merge it
> into another one?

For this I think you could actually move the existing bugs to
Core:General and remove the component entierly.

/ Jonas

Andrew Schultz

unread,
Jun 14, 2007, 8:28:31 PM6/14/07
to
Robert Kaiser wrote:
> - 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.

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).

--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/

Steffen Wilberg

unread,
Jun 15, 2007, 5:33:23 AM6/15/07
to
On 14 Jun., 09:44, Gervase Markham <g...@mozilla.org> wrote:
> Steffen Wilberg wrote:
> > Let's move "Startup and Profile System" to toolkit, and merge it with
> > "XRE Startup".
> > mozilla/toolkit/profile/
>
> With the new name being "Startup and Profile System"?
I guess so, since it covers both the toolkit startup code in
http://mxr.mozilla.org/seamonkey/source/toolkit/xre/
and the profile manager in
http://mxr.mozilla.org/seamonkey/source/toolkit/profile/.

Steffen

Steffen Wilberg

unread,
Jun 15, 2007, 5:42:57 AM6/15/07
to
As was suggested before (and in bug 271978), we should move Plugin
Finder Service to toolkit since the code lives there (http://
mxr.mozilla.org/seamonkey/source/toolkit/mozapps/plugins/) and
Seamonkey wants to make use of it as well.

Steffen

Steffen Wilberg

unread,
Jun 15, 2007, 5:57:02 AM6/15/07
to
On 14 Jun., 16:57, Gervase Markham <g...@mozilla.org> wrote:
> Alex Vincent wrote:
> > 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.
>
> Gerv

Already done :-)
Steffen

Steffen Wilberg

unread,
Jun 15, 2007, 6:30:43 AM6/15/07