Organization of Core and Toolkit products in Bugzilla
Robert Kaiser
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
> 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
> 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
>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
> 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
> 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
> 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
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
> 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
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
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
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
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
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
mozilla/toolkit/components/viewsource/
Steffen Wilberg
"XRE Startup".
mozilla/toolkit/profile/
Steffen Wilberg
sometimes it when downloading large attachments. Seamonkey uses it as
well or will do so soon.
mozilla/toolkit/mozapps/downloads/
Steffen Wilberg
Thunderbird as well.
mozilla/toolkit/mozapps/update/
Jonas Sicking
/ Jonas
Jonas Sicking
categories.
/ Jonas
Jonas Sicking
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
Ports: Qt
Widget: Photon
Widget: Xlib
has been alive in a long time, right?
/ Jonas
Justin Wood (Callek)
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
Regarding Photon:
https://bugzilla.mozilla.org/show_bug.cgi?id=376791#c4
Qt and Xlib have been removed.
/Mats
Gervase Markham
> 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
With the new name being "Startup and Profile System"?
Gerv
Gervase Markham
> 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
> 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
> 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
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
mostly a no-brainer.
Mmm. Braaaaaains.
Justin
Dave Townsend
> 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
> 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
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
Alex Vincent
> 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
> 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
cheers,
mike
Mmm. Braaaaaains.
Justin
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Robert Kaiser
> 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
> 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
> 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
IIRC, it is obsolete already, it should move into a closed obsolete
product like you proposed in the xprint subthread.
Robert Kaiser
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
Gervase Markham
> 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
- 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
> 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
> 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
moving all the (closed) bugs to an existing component better in any
way than abandoning the whole component?
Nickolay
Simon Paquet
>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
>Let's move Software Update from Firefox to toolkit. It's used by
>Thunderbird as well.
>mozilla/toolkit/mozapps/update/
Tony Mechelynck
> 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
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
> - 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
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
Absolutely. The categories listed above are all in Core and the "XUL
Widgets" in Toolkit should remain as is.
/ Jonas
Robert Kaiser
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
> 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.
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
> 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
> 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)
> 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)
agreed, heavily.
~Justin Wood (Callek)
Benjamin Smedberg
> 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)
> 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)
>
> up "xre" and "xpfe".
Yep, must be, thanks for clarifying that for me.
~Justin Wood (Callek)
Jonas Sicking
> 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
> - 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
> 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"?
http://mxr.mozilla.org/seamonkey/source/toolkit/xre/
and the profile manager in
http://mxr.mozilla.org/seamonkey/source/toolkit/profile/.
Steffen
Steffen Wilberg
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
> 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
Toolkit:Satchel. Since the latter is badly named, the new name should
be Toolkit:Form Manager.
The code lives in http://mxr.mozilla.org/seamonkey/source/toolkit/components/satchel/
Steffen
Gervase Markham
> XRE is the toolkit startup system, and is quite alive. I think you're mixing
> up "xre" and "xpfe".
OK, so I've moved "Startup and Profile System" to Toolkit, but not
merged in XRE Startup.
Gerv
Gervase Markham
> 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.
Kairo: Do you guys want to keep these components around for a bit?
Gerv
Gervase Markham
> I think we should move those either to the "Other Applications" product
> or create a new MailNews product for that shared code.
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
Benjamin Smedberg
They should be the same component, I can't see any difference between them.
--BDS
Gervase Markham
> They should be the same component, I can't see any difference between them.
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
Robert Kaiser
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
Robert Kaiser
> Robert Kaiser wrote:
>> I think we should move those either to the "Other Applications"
>> product or create a new MailNews product for that shared code.
>
> 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?).
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
Gervase Markham
> 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.
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
Justin Wood (Callek)
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)
Nelson Bolyard
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.
Steffen Wilberg
Find as you Type", since the code is in toolkit and is used by other
apps like Thunderbird as well:
http://mxr.mozilla.org/seamonkey/find?string=findbar
http://mxr.mozilla.org/seamonkey/source/toolkit/components/typeaheadfind/
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
Robert Kaiser
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
Robert Kaiser
> 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.
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
timeless
> 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.
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.
David E. Ross
> Robert Kaiser wrote:
>> 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
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
Tony Mechelynck
[...]
> Under Core, there is a Talkback Client component. I thought Talkback
> was being replaced by an open-source application.
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.
Tony Mechelynck
> David E. Ross wrote:
> [...]
>> Under Core, there is a Talkback Client component. I thought Talkback
>> was being replaced by an open-source application.
> [...]
>
> 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.
...oops! FullCircle Talkback.
See also (among others) https://bugzilla.mozilla.org/show_bug.cgi?id=380540
>
>
> Best regards,
> Tony.
Gervase Markham
> 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)?
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
Gervase Markham
> I've classically proposed product "Graveyard" and with component names
> describing what things were.
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
Gervase Markham
> Let's move Firefox:Find Toolbar / FastFind to "Toolkit: Find Toolbar /
> Find as you Type",
Can't we just call it "Toolkit" / "Find"?
Gerv
Gervase Markham
> 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.
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
Robert Kaiser
> 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.
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
Steffen Wilberg
I think "Find as you Type" is more descriptive and is less likely to be
confused with "Search" (which is a Firefox component).
Steffen
Steffen Wilberg
How about "Find in Page", matching the respective component in Core?
Steffen
Justin Wood (Callek)
We could (now) Prefix the other product names with "Graveyard: " now
too, perhaps, to distinguish "at a glance" they are obsoleted.
~Justin Wood (Callek)
Gervase Markham
> We could (now) Prefix the other product names with "Graveyard: " now
> too, perhaps, to distinguish "at a glance" they are obsoleted.
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
Robert Kaiser
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
Robert Kaiser
> Gervase Markham schrieb:
>> "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.
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 Wilberg
> Steffen Wilberg schrieb:
>> Gervase Markham wrote:
>>> Steffen Wilberg wrote:
>>>> Let's move Firefox:Find Toolbar / FastFind to "Toolkit: Find Toolbar
>>>> / Find as you Type",
>>>
>>> Can't we just call it "Toolkit" / "Find"?
>>>
>>> Gerv
>>
>> I think "Find as you Type" is more descriptive and is less likely to
>> be confused with "Search" (which is a Firefox component).
>
> If those can be confused, maybe both are not named correctly. "Search"
> is short and nice, but what search is this about? Web search?
click->Search (selected engine) for "(selection)".
It uses the selected search engine to search the web or specific sites
like Amazon, eBay etc. Basically everything except Find In Page.
So "Web Search" isn't quite right either, since that suggests searching
the *whole* web like Google or Yahoo does.
Steffen
Robert Kaiser
> Robert Kaiser wrote:
>> Steffen Wilberg schrieb:
>>> be confused with "Search" (which is a Firefox component).
>>
>> If those can be confused, maybe both are not named correctly. "Search"
>> is short and nice, but what search is this about? Web search?
> It is about the search toolbar and related uses like selection->right
> click->Search (selected engine) for "(selection)".
> It uses the selected search engine to search the web or specific sites
> like Amazon, eBay etc. Basically everything except Find In Page.
> So "Web Search" isn't quite right either, since that suggests searching
> the *whole* web like Google or Yahoo does.
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
Mike Connor
- Mike
-----Original Message-----
From: Robert Kaiser <ka...@kairo.at>
Date: Sat, 23 Jun 2007 01:39:50
To:dev-pl...@lists.mozilla.org
Subject: Re: Proposal: move Firefox:Find Toolbar / FastFind to toolkit
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning