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
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
> 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
>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
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
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
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
Gerv
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:
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
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
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"
So I propose to move Error Console to Toolkit. Thunderbird uses the same
thing, and the code is in mozilla/toolkit/components/console.
Steffen
/ Jonas
/ Jonas
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
Ports: Qt
Widget: Photon
Widget: Xlib
has been alive in a long time, right?
/ Jonas
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)
Regarding Photon:
https://bugzilla.mozilla.org/show_bug.cgi?id=376791#c4
Qt and Xlib have been removed.
/Mats
We'd try and make sure that didn't happen this time.
Gerv
With the new name being "Startup and Profile System"?
Gerv
Where do the bugs go? Do you want to obsolete the component, or merge it
into another one?
Gerv
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
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
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
Mmm. Braaaaaains.
Justin
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.
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
> 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
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
cheers,
mike
Mmm. Braaaaaains.
Justin
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
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
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
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
IIRC, it is obsolete already, it should move into a closed obsolete
product like you proposed in the xprint subthread.
Robert Kaiser
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
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
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
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
>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
>Let's move Software Update from Firefox to toolkit. It's used by
>Thunderbird as well.
>mozilla/toolkit/mozapps/update/
... 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?
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
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
- 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
Absolutely. The categories listed above are all in Core and the "XUL
Widgets" in Toolkit should remain as is.
/ Jonas
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
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
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
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. :)
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)
agreed, heavily.
~Justin Wood (Callek)
XRE is the toolkit startup system, and is quite alive. I think you're mixing
up "xre" and "xpfe".
--BDS
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.
/ Jonas
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
Steffen
Already done :-)
Steffen
Steffen
OK, so I've moved "Startup and Profile System" to Toolkit, but not
merged in XRE Startup.
Gerv
Kairo: Do you guys want to keep these components around for a bit?
Gerv
So this would be a component for those bits of the platform which are
specific to MailNews? (I.e. shared between SeaMonkey and Thunderbird,
but mail-specific?).
"MailNews Platform"? (If we end up merging Core and Toolkit into
"Platform"). Or "MailNews Core"?
It needs to have some sort of name association to its partner component,
IMO.
Before I can do this, I need an exact proposed list of components to move.
Gerv
They should be the same component, I can't see any difference between them.
--BDS
Sorry, I read it as if you were opposing this merge. I'll fix that and
merge it in, with the result being in "Toolkit" for the moment.
Gerv
I think the few branch bugs that might come up can go into the
SeaMonkey-specific components for UI, and on trunk this is dead.
Robert Kaiser
Well, this code is not part of the XULRunner platform actually and only
built by SeaMonkey and Thunderbird AFAICT (Penelope probably, however
that one manifests itself).
> "MailNews Platform"? (If we end up merging Core and Toolkit into
> "Platform"). Or "MailNews Core"?
Because of it not being a part of XULRunner, I feel it might be good to
avoid the association with the XULRunner "Platform" product - but I
might be wrong in that.
> Before I can do this, I need an exact proposed list of components to move.
I'll try to compose such a list early next week, at least all of
Core::MailNews:* should move there, though, AFAICT.
Robert Kaiser
At the moment, XP Toolkit/Widgets.* have been combined into a new "XUL"
component, as suggested elsewhere in this large thread. Do you want to
argue that's a bad plan?
Gerv
I read his statement as he was "ok" with the removal of the XP
Toolkit/Widgets* stuff.
And though I can't really speak for him ( :-) ) I'll say I'm ok with it.
~Justin Wood (Callek)
I have the impression that the vast majority of Thunderbird bugs are
actually common to SeaMonkey, and thus should be "Core mail/news".
So, I'm thinking maybe we need a new "product" in b.m.o, which is mailnews,
and let Thunderbird UI be a component of it, and Seamonkey mail UI be another
component of it.
I'd have suggested to merge in "Core:Keyboard: Find as you Type" as
well, but it looks like that is about the code in
mozilla/extensions/typeaheadfind, which is only used by Seamonkey and
Camino:
http://mxr.mozilla.org/seamonkey/search?string=typeaheadfind&find=confvars.sh&findi=&filter=&tree=seamonkey
Steffen
No, this is a good plan and works well for us.
I just suggested that if the xpfe still used by us on branch shows up
any bugs that are still valid against branch (security or crash issues,
probably nothing else) and don't belong into whatever that ends up in,
we can still deal with it in some SeaMonkey component.
Robert Kaiser
The new product has been suggested elsewhere, the SeaMonkey- or
Thunderbird-specific parts should be tracked in their respective
products though, only the actually shared code should be tracked in the
MailNews core component.
Robert Kaiser
I've classically proposed product "Graveyard" and with component names
describing what things were.
Grendel components aren't platform, they'd just land in graveyard. I
don't think you ever need more than one graveyard.
Two comments on Reorganisation Plan version 0.2:
Under Thunderbird, for which component would I submit a bug report about
View and its options (e.g., options on the View menus from the menu bar,
problems with threaded views, viewing message headers)?
Under Core, there is a Talkback Client component. I thought Talkback
was being replaced by an open-source application.
Also, a general comment:
When I was a software test engineer, I was also the configuration
manager for the software my group tested. From that experience, I
believe there is nothing wrong with having distinct Bugzilla components
that divide a single developer component. That is, the relationship
does not have to be 1-to-1. Instead, one developer component could
trace to several Bugzilla components; but each Bugzilla component must
trace back to a single developer component.
For example (relative to my Thunderbird comment above), there are so
many open bug reports against view options, threaded views, and viewing
message headers that a distinct Thunderbird component of View in
Bugzilla might be appropriate.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Work is in progress to replace Talkback, at some future time, by an
open-source component. But it isn't done yet, and AFAIK the only crash-trace
component (if any) which ships with current versions of Firefox, Thunderbird,
SeaMonkey, et al., is FullCircle Traceback.
Best regards,
Tony.
--
New crypt. See /usr/news/crypt.
...oops! FullCircle Talkback.
See also (among others) https://bugzilla.mozilla.org/show_bug.cgi?id=380540
>
>
> Best regards,
> Tony.
My job is not to analyse all our software and make suggestions as to
appropriate Bugzilla components, it's to collate concrete suggestions
for change from those who do have the knowledge :-) So my answer is: ask
a Thunderbird developer :-)
> Under Core, there is a Talkback Client component. I thought Talkback
> was being replaced by an open-source application.
It is, but we aren't there yet.
Gerv
Good name; adopted.
> Grendel components aren't platform, they'd just land in graveyard. I
> don't think you ever need more than one graveyard.
Well, we already have "graveyarded" products like MozillaClassic and
Derivatives, and they stay as products. So I think we should keep
Grendel as a product too.
Gerv
Can't we just call it "Toolkit" / "Find"?
Gerv
Note that the new name "Privacy, Passwords & Permissions" contains a
comma, and so falls foul of:
https://bugzilla.mozilla.org/show_bug.cgi?id=67036
which makes it impossible to query for components with commas.
Would "Privacy & Passwords" do?
Gerv
Uh, I wasn't aware of that.
> Would "Privacy & Passwords" do?
Hrm, not sure if people realize that this is also for PopUp/Image
blocking and Cookies UI...
I'm not yet sure what we would prefer to do with that name...
Robert Kaiser
I think "Find as you Type" is more descriptive and is less likely to be
confused with "Search" (which is a Firefox component).
Steffen
How about "Find in Page", matching the respective component in Core?
Steffen
We could (now) Prefix the other product names with "Graveyard: " now
too, perhaps, to distinguish "at a glance" they are obsoleted.
~Justin Wood (Callek)
Better would be to put them in a "Graveyard" classification... I've done
that. See what you think. I don't think you can have two Products with
the same name, even in different classifications, so I've called the one
with Core bits in "Core Graveyard".
Gerv
If those can be confused, maybe both are not named correctly. "Search"
is short and nice, but what search is this about? Web search? If so, it
should probably be named that way.
Robert Kaiser
Could you create a "MailNews Core" product in your list and seed it with
Core::MailNews:* (stripping the MailNews: prefix from all) for now?
It looks like the MailNews devs are currently too busy to tell me what
other components from Thunderbird and SeaMonkey should go there, but
those from Core are definitely correct there and a good start.
Robert Kaiser
Steffen
So, IMHO, "Web Search" is correct as it is a search function that is
done via the web (contrary to a local search done in an already
displayed page).
Robert Kaiser