Last Call for b.m.o. reorganisation plan
Gervase Markham
component/product reorganisation plan:
http://www.gerv.net/temp/bmo-reorg.html
Please do not make further suggestions for change; the time for that (in
this round, at least) is past. I am interested only in objections to
proposed changes, which are highlighted in red on the page above.
I apologise for the cross-posting, but I wouldn't want anyone to say
that they weren't informed. I have tried to hit groups where the
most-affected communities live.
Gerv
fantasai
> This is the final call for people to object to aspects of the b.m.o.
> component/product reorganisation plan:
> http://www.gerv.net/temp/bmo-reorg.html
>
> Please do not make further suggestions for change; the time for that (in
> this round, at least) is past. I am interested only in objections to
> proposed changes, which are highlighted in red on the page above.
I expect we'll get a lot of Layout: Printing bugs still filed under Printing,
since it's not clear what the distinction is. Clarifying what Printing is
supposed to be for might be a good idea. I don't have any suggestions, though.
~fantasai
Boris Zbarsky
> I expect we'll get a lot of Layout: Printing bugs still filed under
> Printing,
> since it's not clear what the distinction is.
Er... what _is_ the distinction?
-Boris
fantasai
Boris Zbarsky
> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/55b9096e56ef28d1/5eaddd0c3bf30766#5eaddd0c3bf30766
Yeah, if that's the distinction then the current component names are no good,
imo. I had assumed that the ui component would get renamed in the process.
How about "Layout: Printing" and "Page Setup".
Or even "Printing: Output" and "Printing: Setup"? Users filing a bug are not
likely to ever find "Layout: Printing" when filing a print bug....
-Boris
Dave Townsend
> This is the final call for people to object to aspects of the b.m.o.
> component/product reorganisation plan:
> http://www.gerv.net/temp/bmo-reorg.html
I would suggest that it might be good to get the question about merging
toolkit and core to some kind of conclusion. bsmedberg and mconnor had
some good points but it never really got anywhere. I imagine it'd be
better to get a conclusion there now that have it come up again after
the reorg has happened.
Dave
David E. Ross
If "Core" is the Gecko engine used by both Firefox and Thunderbird
(which apparently is true), I strongly suggest it be named "Gecko Core".
If "MailNews Core" includes the Gecko engine for Thunderbird (which
apparently is NOT true), then "Core" should be named "Browser Core".
There are several other "core" components. Thus, having a product named
merely "Core" can be confusing.
--
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
Rolf
Gervase Markham wrote:
> This is the final call for people to object to aspects of the b.m.o.
> component/product reorganisation plan:
> http://www.gerv.net/temp/bmo-reorg.html
>
The link above gives me a popup displaying this message:
Warning: Unresponsive script
A script on this page may be busy, or it may have stopped responding.
You can stop the script now, or you can contiue to see if the script
will complete. *Stop script* *Continue*
And the following message is shown in the JavaScript Console:
Error: Error in parsing value for property 'min-height'. Declaration
dropped.
Source File: http://www.gerv.net/temp/tree/tree.css
Line: 123
After selecting *Stop script* these two messages are added:
Error: [Exception... "'Permission denied to get property
XULElement.accessKey' when calling method:
[nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame ::
http://www.gerv.net/temp/tree/tree.js :: initTree :: line 80" data: no]
Source File: http://www.gerv.net/temp/tree/tree.js
Line: 80
Error: [Exception... "'Permission denied to get property
XULElement.accessKey' when calling method:
[nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame ::
http://www.gerv.net/temp/tree/tree.js :: initTree :: line 80" data: no]
Source File: http://www.gerv.net/temp/tree/tree.js
Line: 80
Anyone else experiencing the same?
--
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.12) Gecko/20070510
SeaMonkey/1.0.9 - Classic Theme - 266MHz Mobile Pentium II 288MB RAM
Jonas Sicking
Since the "DOM" category is no longer around, I think it might be useful
to have a "Content" category (under "core") for things that are internal
to our content code. Traditionally I've filed such things under "DOM",
which has never really been great.
/ Jonas
Axel Hecht
The changes to the localization components are not OK. They're partly
inconsistent, and I guess that some are just plain wrong.
That needs further investigation, I just want to note that at least the
Norwegian and South African language changes look fishy. Like, the name
of the language is Nothern Sotho, not Sotho (Nothern). And there doesn't
seem to be a Southern Pedi. Similar concerns for the rest of the changes
there.
Axel
Steve Wendt
> This is the final call for people to object to aspects of the b.m.o.
> component/product reorganisation plan:
> http://www.gerv.net/temp/bmo-reorg.html
It seems like some of these should just be in Toolkit, instead of moving
from Core to Seamonkey (possibly others as well). Or is it "too soon"
since only Seamonkey trunk is using toolkit?
Error Console
Keyboard: Find as you Type (same as Find In Page?)
Location Bar \
Autocomplete / merge and move from Firefox to Core?
Search
Tabbed Browser
Themes
Similarly, can't most of Seamonkey's MailNews components be moved/merged
with the new MailNews Core components?
What does Layout: Printing cover that Print Preview and Printing don't?
Why make this one inconsistent from the others?
Image: Layout [renamed from Layout: Images]
Tony Mechelynck
Under "Mozilla Localizations", isn't there a typo in the line "nb-NO /
Norwegian (Bokmal)" which is in red -- shouldn't it be (Bokmål) with a-ball,
or, if you want 7-bit ASCII, (Bokmaal) with a-ball transliterated as aa? Maybe
ask someone from Norway; see also http://en.wikipedia.org/wiki/Bokm%C3%A5l
http://en.wikipedia.org/wiki/%C3%85#Transcription /et al./
Best regards,
Tony.
--
CUSTOMER: Well, can you hang around a couple of minutes? He won't be
long.
MORTICIAN: Naaah, I got to go on to Robinson's -- they've lost nine today.
CUSTOMER: Well, when is your next round?
MORTICIAN: Thursday.
DEAD PERSON: I think I'll go for a walk.
The Quest for the Holy Grail (Monty Python)
Samuel Sidler
> Please do not make further suggestions for change; the time for that (in
> this round, at least) is past. I am interested only in objections to
> proposed changes, which are highlighted in red on the page above.
Renaming "Sumo" to "support.mozilla.com" is kind of weird now since it's
actually being called "Sumo" (or sometimes "SUMO") in the newsgroup,
blog posts, and other written works. I understand the idea, but anyone
who works on it will know what it is at this point. I'd at least run it
by chofmann before making the change.
-ss
Axel Hecht
> Op Donderdag 12-07-2007 om 17:16 uur [tijdzone +0100], schreef Gervase
> Markham:
>
> I spotted these two South African locales:
>
> * nr / Ndebele
> * nso / Sotho/Pedi (Northern) [change order; add brackets]
>
> nr is Southern Ndebele, so it should probably be Ndebele (South)
> according to the convention. It is commonly just called Ndebele in South
> Africa, but there is also Northern Ndebele that is spoken in Zimbabwe.
>
> The name for nso seems a bit confusing, since it almost seems like
> Sotho / Northern Pedi. I would say the best is "Sotho (North)" and to
> drop the Pedi. The name(s) of this language is a bit of an issue for
> some people, so we can leave the Pedi part in, but then at least with a
> reordering that makes more sense: "Sotho (North) / Pedi".
>
> I can go into the details of Pedi vs Northern Sotho if you are
> interested, but I guess for bugzilla it doesn't really matter that much
> either way.
I don't think that we should do the () dance for the South African
languages at all. The language name is Nothern Sotho, and there is no
reason to change that on our behalf.
Axel
Axel Hecht
http://groups.google.com/group/mozilla.support.planning/browse_frm/thread/afba396de61c835e/c5666772a011038d#c5666772a011038d
is already there, for a month.
We still call it devmo, even if it's spelled MDC, too, so that's not a
problem in general.
Axel
Robert Kaiser
> It seems like some of these should just be in Toolkit, instead of moving
> from Core to Seamonkey (possibly others as well). Or is it "too soon"
> since only Seamonkey trunk is using toolkit?
This has been extensively discussed here, it's correct that they are in
SeaMonkey for the time being, but we might move them once again in only
a few months, letting them find their final resting place in the Graveyard.
> Similarly, can't most of Seamonkey's MailNews components be moved/merged
> with the new MailNews Core components?
No, most of the UI is forked between Thunderbird and SeaMonkey, only the
backend code is shared.
> What does Layout: Printing cover that Print Preview and Printing don't?
See other subthread in here.
> Why make this one inconsistent from the others?
> Image: Layout [renamed from Layout: Images]
To make it consistent with the other "Image: xxx" ones instead, which
makes more sense.
Oh, and please don't 1) disregard a Followup-to and/or 2) cross-post
without a Followup-to.
Robert Kaiser
Robert Kaiser
> This is the final call for people to object to aspects of the b.m.o.
> component/product reorganisation plan:
> http://www.gerv.net/temp/bmo-reorg.html
Two simple requests for adjusting names of moved/changed components:
wrt the "Privacy, Password & Permissions" name that probably causes
search problems, I think that going with "Passwords & Permissions" might
probably be OK, as it mainly covers password stuff but also
cookie/image/etc permissions.
And "Keyboard: Find as you Type" should probably be name "Find In Page",
which matches the name for the parallel component in Core.
And lots of thanks for getting some action on this. It may not be the
last Bugzilla organization change, but definitely a very good and long
overdue step!
Robert Kaiser
Jean-Marc Desperrier
> I see "Core" and "MailNews Core".
>
> If "Core" is the Gecko engine used by both Firefox and Thunderbird
> (which apparently is true), I strongly suggest it be named "Gecko Core".
>
> If "MailNews Core" includes the Gecko engine for Thunderbird (which
> apparently is NOT true), then "Core" should be named "Browser Core".
>
> There are several other "core" components. Thus, having a product named
> merely "Core" can be confusing.
I think the proper solution is "Gecko Core".
And that "MailNews Core/ BiDi Hebrew & Arabic" should be merged with
"Core/ Layout: Text"
There's a few other "MailNews Core" components that, to various degrees,
I'm not convinced really need to exist but maybe should instead be
merged with gecko core : Internationalization, Localization, Printing,
Security, Profile Migration and Networking.
I mean we either need all of "Gecko Core", "Browser Core" and "MailNews
Core" or we instead sometime put within "Gecko Core" some elements that
despite being really core and reusable in other contexts are only
actually used inside browser or inside mail.
I feel the current suggestion carefully avoids to put anything only used
by mail inside Core, but that they are many things only used by browser
inside Core.
Samuel Sidler
I saw it before, which is why I said "now". It doesn't matter too much,
I suppose, just weird to call it "Sumo" everywhere and then tell people
to file bugs on "support.mozilla.com" which isn't in the standard
"Websites" product like similarly-named components. (And yes, I realize
that support.mozilla.com will be / is a product not a component.) This
would be akin to renaming MDC to "developer.mozilla.org" in bugzilla, in
my mind.
-ss
Chris Ilias
> I saw it before, which is why I said "now". It doesn't matter too much,
> I suppose, just weird to call it "Sumo" everywhere and then tell people
> to file bugs on "support.mozilla.com" which isn't in the standard
> "Websites" product like similarly-named components. (And yes, I realize
> that support.mozilla.com will be / is a product not a component.) This
> would be akin to renaming MDC to "developer.mozilla.org" in bugzilla, in
> my mind.
On the same note, the addons.mozilla.org product is not named "AMO". If
the MDC folks feel that "MDC" is the best name for the bugzilla listing,
that's up to them; and I'm in no position to criticize them for it. To
me, I think that if a person is familiar with the term "SUMO", we don't
need to worry about that person being confused, when they see
"support.mozilla.com"; whereas there's a much greater chance of someone
not knowing what SUMO means, no matter how much current contributors
refer to it as such. We are always going to have newbie contributors,
particularly in user support; and this is a pointless barrier.
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Gervase Markham
> I would suggest that it might be good to get the question about merging
> toolkit and core to some kind of conclusion. bsmedberg and mconnor had
> some good points but it never really got anywhere. I imagine it'd be
> better to get a conclusion there now that have it come up again after
> the reorg has happened.
I have agreed with mconnor and bsmedberg to defer this until after this
round of reorganisation, so it's not a blocker.
Gerv
Gervase Markham
> Or even "Printing: Output" and "Printing: Setup"? Users filing a bug
> are not likely to ever find "Layout: Printing" when filing a print bug....
Those sound good to me. Changed; people should object and propose better
names if they don't like them.
Gerv
Gervase Markham
> I see "Core" and "MailNews Core".
>
> If "Core" is the Gecko engine used by both Firefox and Thunderbird
> (which apparently is true), I strongly suggest it be named "Gecko Core".
I don't believe that the Bugzilla product "Core" and the concept of
"Gecko" have a direct correspondence. I think Gecko is probably a subset
of Core, although I could be wrong.
MailNews Core is a specialist subdivision of Core; we can't reflect it
using a subhierarchy because there aren't enough levels. So we do so
through the name. Perhaps "Core: MailNews" would be more consistent with
other places where we do this.
> If "MailNews Core" includes the Gecko engine for Thunderbird (which
> apparently is NOT true), then "Core" should be named "Browser Core".
This is definitely not true.
Gerv
Gervase Markham
> I think the proper solution is "Gecko Core".
I'd want some other core hackers to weigh in, but as I understand it,
this name would be incorrect.
> And that "MailNews Core/ BiDi Hebrew & Arabic" should be merged with
> "Core/ Layout: Text"
We can certainly do that, irrespective of what happens with MailNews
Core. Done.
> There's a few other "MailNews Core" components that, to various degrees,
> I'm not convinced really need to exist but maybe should instead be
> merged with gecko core : Internationalization, Localization, Printing,
> Security, Profile Migration and Networking.
Well, if you turn that "maybe" into a concrete proposal, we can
certainly do it. :-) If this means that MailNews Core only has three
components, then perhaps we don't need a separate product after all.
> I feel the current suggestion carefully avoids to put anything only used
> by mail inside Core, but that they are many things only used by browser
> inside Core.
This may be true; however, the fact that we have a MailNews Core doesn't
mean that we automatically have to have a Browser Core. Otherwise we
might get a Calendar Core, and so on and so on. MailNews has a large,
fairly-well-defined subset of code which it alone uses, and so it was
considered useful to split it out.
Gerv
Gervase Markham
> Since the "DOM" category is no longer around, I think it might be useful
> to have a "Content" category (under "core") for things that are internal
> to our content code. Traditionally I've filed such things under "DOM",
> which has never really been great.
You need to get together with the relevant people and produce a concrete
proposal.
Gerv
Gervase Markham
> The changes to the localization components are not OK. They're partly
> inconsistent, and I guess that some are just plain wrong.
OK, if they are inconsistent, then that's definitely a bug, as the
entire aim was to make them consistent.
> That needs further investigation, I just want to note that at least the
> Norwegian and South African language changes look fishy.
I'm fairly sure the Norwegian changes are right.
http://en.wikipedia.org/wiki/Norwegian_language
The two types are different forms of written Norwegian; "The Norwegian
Language Council recommends the terms "Norwegian Bokmål" and "Norwegian
Nynorsk" in English." I think that my version is close to that, while
keeping consistency with other subdivisions/dialects in the list.
> Like, the name
> of the language is Nothern Sotho, not Sotho (Nothern). And there doesn't
> seem to be a Southern Pedi.
http://en.wikipedia.org/wiki/Northern_Sotho_language gives some more
clarity. Perhaps we need to ask the localisers. If they are doing it
into the Pedi dialect of Northern Sotho, then probably what we want is:
nso / Northern Sotho (Pedi)
> Similar concerns for the rest of the changes
> there.
Can you please be more specific about your objections? I'm sure you
don't object to tidying up spacing, order of code/name or comma
placement, for example.
Gerv
Gervase Markham
> Under "Mozilla Localizations", isn't there a typo in the line "nb-NO /
> Norwegian (Bokmal)" which is in red -- shouldn't it be (Bokmål) with
> a-ball, or, if you want 7-bit ASCII, (Bokmaal) with a-ball
> transliterated as aa? Maybe ask someone from Norway; see also
> http://en.wikipedia.org/wiki/Bokm%C3%A5l
> http://en.wikipedia.org/wiki/%C3%85#Transcription /et al./
I'm not sure if Bugzilla can do the a-ring; if it can, I will add it.
The original component used "bokmal", but you are right - bokmaal seems
to be more correct.
Gerv
Gervase Markham
> wrt the "Privacy, Password & Permissions" name that probably causes
> search problems, I think that going with "Passwords & Permissions" might
> probably be OK, as it mainly covers password stuff but also
> cookie/image/etc permissions.
Done.
> And "Keyboard: Find as you Type" should probably be name "Find In Page",
> which matches the name for the parallel component in Core.
Done.
Gerv
Gervase Markham
> I spotted these two South African locales:
Hi Friedel,
Please try and respect the Followup-To header; I might not have noticed
your message if Axel had not replied to it.
> * nr / Ndebele
> * nso / Sotho/Pedi (Northern) [change order; add brackets]
>
> nr is Southern Ndebele, so it should probably be Ndebele (South)
> according to the convention. It is commonly just called Ndebele in South
> Africa, but there is also Northern Ndebele that is spoken in Zimbabwe.
Makes sense, and Wikipedia agrees. Fixed.
> The name for nso seems a bit confusing, since it almost seems like
> Sotho / Northern Pedi. I would say the best is "Sotho (North)" and to
> drop the Pedi. The name(s) of this language is a bit of an issue for
> some people, so we can leave the Pedi part in, but then at least with a
> reordering that makes more sense: "Sotho (North) / Pedi".
I've changed it to
Northern Sotho (Pedi) for reasons explained in my message in
mozilla.dev.planning. Do comment in that newsgroup if you think this
isn't right.
It rather depends on exactly what the intent of the localisers is. If
they are localising specifically into the Pedi dialect of Northern
Sotho, then the above is correct. If the word "Pedi" is in there because
it's an alternative name for the language Northern Sotho, then perhaps
we just need to remove it.
Gerv
Tony Mechelynck
IIRC, the current version of bugzilla.mozilla.org uses Unicode throughout, so
I expect the a-ring to be displayable. I don't know the details though, so I
can't be sure it applies to products and components.
Best regards,
Tony.
--
Someone will try to honk your nose today.
David E. Ross
> David E. Ross wrote:
>> I see "Core" and "MailNews Core".
>>
>> If "Core" is the Gecko engine used by both Firefox and Thunderbird
>> (which apparently is true), I strongly suggest it be named "Gecko Core".
>
> I don't believe that the Bugzilla product "Core" and the concept of
> "Gecko" have a direct correspondence. I think Gecko is probably a subset
> of Core, although I could be wrong.
Yes, Core is more than Gecko.
The point is that having a component named "Core" and other components
named "xxx Core" is confusing, especially when the latter are not
subsidiary within the former. If the unqualified "Core" is common to
many products -- including products that also have "xxx Core" -- how
about "Mozilla Core"?
Alternatively, either reserve "Core" for only the unqualified component
(thus not using it elsewhere) or else completely rename that component
to remove "Core" (thus reserving the word for "xxx Core" components).
By the way, the old and new trees at
<http://www.gerv.net/temp/bmo-reorg.html>, both show "Core" directly
under "Components". The hierarchy seen when I do a Bugzilla query
indicates "Core" is a product with components under it. The use of
"Components" as a term within the classification trees is itself
confusing: Is "Components" a product or a component?
Further confusing things, both trees have an unqualified "Core"
component under "Rhino".
Gervase Markham
> The point is that having a component named "Core" and other components
> named "xxx Core" is confusing, especially when the latter are not
> subsidiary within the former. If the unqualified "Core" is common to
> many products -- including products that also have "xxx Core" -- how
> about "Mozilla Core"?
I'm not sure that change would provide any extra clarity.
> By the way, the old and new trees at
> <http://www.gerv.net/temp/bmo-reorg.html>, both show "Core" directly
> under "Components".
That is correct; there is a Classification called "Components" in Bugzilla.
> The hierarchy seen when I do a Bugzilla query
> indicates "Core" is a product with components under it.
Indeed, it is.
> The use of
> "Components" as a term within the classification trees is itself
> confusing: Is "Components" a product or a component?
Neither :-) It's a Classification (the one above Product).
If you think this is a confusing name, suggest a better one and build
consensus. But I haven't seen any confusion caused by it.
> Further confusing things, both trees have an unqualified "Core"
> component under "Rhino".
I can't really control what the Rhino developers choose to call their
components... :-)
Gerv
Axel Hecht
> Axel Hecht wrote:
>> The changes to the localization components are not OK. They're partly
>> inconsistent, and I guess that some are just plain wrong.
>
> OK, if they are inconsistent, then that's definitely a bug, as the
> entire aim was to make them consistent.
>
>> That needs further investigation, I just want to note that at least
>> the Norwegian and South African language changes look fishy.
>
> I'm fairly sure the Norwegian changes are right.
> http://en.wikipedia.org/wiki/Norwegian_language
> The two types are different forms of written Norwegian; "The Norwegian
> Language Council recommends the terms "Norwegian Bokmål" and "Norwegian
> Nynorsk" in English." I think that my version is close to that, while
> keeping consistency with other subdivisions/dialects in the list.
I don't see a value in being consistent within bugzilla compared to
being consistent to an official language institute recommendation.
Let's just use "Norwegian Bokmål" and "Norwegian Nynorsk" instead.
>> Like, the name of the language is Nothern Sotho, not Sotho (Nothern).
>> And there doesn't seem to be a Southern Pedi.
>
> http://en.wikipedia.org/wiki/Northern_Sotho_language gives some more
> clarity. Perhaps we need to ask the localisers. If they are doing it
> into the Pedi dialect of Northern Sotho, then probably what we want is:
> nso / Northern Sotho (Pedi)
>
>> Similar concerns for the rest of the changes there.
>
> Can you please be more specific about your objections? I'm sure you
> don't object to tidying up spacing, order of code/name or comma
> placement, for example.
As discussed in mail, the changes to the locale codes are OK. Whitespace
and ordering is good, too.
For the braces language names changes, that seems to be mostly OK,
Norwegian aside, as noted above, and I'm not sure about Southern Sotho.
I don't really see the () stuff as an important thing. It's OK when it
turns down to clear regional specifications, like for English or
Spanish. But when it references variances of languages, we should just
stick to the full language name.
I guess we should do a follow-up to fix the component descriptions in a
second run,
https://bugzilla.mozilla.org/describecomponents.cgi?product=Mozilla%20Localizations
Axel
Jonas Sicking
What exactly do you need? I talked with jst, bz and dbaron and they were
all for it. I can ask more people if you want?
/ Jonas
Jonas Sicking
I guess you need the info that goes on the describecomponents list:
Default Asignee: nob...@mozilla.org
Default QA Contact: con...@core.bugs
Descriptiton:
Problems in the code in the mozilla/content directory that does not fall
into one of the DOM components. This is mostly for bugs in internal
classes and architecture.
/ Jonas
Nickolay Ponomarev
> Jonas Sicking wrote:
> > Gervase Markham wrote:
> >> Jonas Sicking wrote:
> >>> Since the "DOM" category is no longer around, I think it might be
> >>> useful to have a "Content" category (under "core") for things that
> >>> are internal to our content code. Traditionally I've filed such
> >>> things under "DOM", which has never really been great.
> >>
as it happens in Firefox's part of bugzilla. Perhaps rename to
something less ambiguous (no specific ideas)?
Nickolay
Akkana Peck
> And "Keyboard: Find as you Type" should probably be name "Find In Page",
> which matches the name for the parallel component in Core.
So it would be "Keyboard: Find in Page" and "Core: Find in Page"?
Or "Find in Page" and "Core: Find in Page"? Either way, there will
be two different categories with the same name?
I thought I knew what "Find as you Type" bugs were ... though
I wasn't clear why it belonged in Keyboard -- what about bugs
on the Firefox widget that shows while you're doing a FAYT?
Or should those be filed somewhere else?
But with two different Find in Page categories, I'm a lot less
clear on the difference. Is it an issue of whether it's a user visible
bug (the non-Core one) vs. a bug visible only when writing new code
(Core)? Will users know the difference?
...Akkana
Jonas Sicking
Not really sure why "content" would be more attractive to filers than
anything else? Maybe "Content model"?
/ Jonas
Gervase Markham
> Gervase Markham wrote:
>> Jonas Sicking wrote:
>>> Since the "DOM" category is no longer around, I think it might be
>>> useful to have a "Content" category (under "core") for things that
>>> are internal to our content code. Traditionally I've filed such
>>> things under "DOM", which has never really been great.
My confusion was your use of the word "category" - I thought you wanted
to prefix some existing components with "Content: " (as some previous
had "DOM: ").
If you mean "component", then I know what you mean :-)
Gerv
Robert Kaiser
> Jean-Marc Desperrier wrote:
>> There's a few other "MailNews Core" components that, to various
>> degrees, I'm not convinced really need to exist but maybe should
>> instead be merged with gecko core : Internationalization,
>> Localization, Printing, Security, Profile Migration and Networking.
>
> Well, if you turn that "maybe" into a concrete proposal, we can
> certainly do it. :-) If this means that MailNews Core only has three
> components, then perhaps we don't need a separate product after all.
I don't think we'd fall to only three components. Still, if most of the
MailNews folks think it's a good idea, it may be that way.
>> I feel the current suggestion carefully avoids to put anything only
>> used by mail inside Core, but that they are many things only used by
>> browser inside Core.
>
> This may be true; however, the fact that we have a MailNews Core doesn't
> mean that we automatically have to have a Browser Core. Otherwise we
> might get a Calendar Core, and so on and so on. MailNews has a large,
> fairly-well-defined subset of code which it alone uses, and so it was
> considered useful to split it out.
Even more, the MailNews Core code is shared between multiple client apps
(at least SeaMonkey and Thunderbird), but is not part of the general
XULRunner core. In this way it may be a bit special.
Robert Kaiser
Robert Kaiser
> Robert Kaiser writes:
>> And "Keyboard: Find as you Type" should probably be name "Find In Page",
>> which matches the name for the parallel component in Core.
>
> So it would be "Keyboard: Find in Page" and "Core: Find in Page"?
> Or "Find in Page" and "Core: Find in Page"? Either way, there will
> be two different categories with the same name?
Yes, but it's "Core:: Find In Page" and "SeaMonkey:: Find In Page".
> I thought I knew what "Find as you Type" bugs were ... though
> I wasn't clear why it belonged in Keyboard -- what about bugs
> on the Firefox widget that shows while you're doing a FAYT?
> Or should those be filed somewhere else?
That goes into the core one - clearly no SeaMonkey bug, right?
> But with two different Find in Page categories, I'm a lot less
> clear on the difference. Is it an issue of whether it's a user visible
> bug (the non-Core one) vs. a bug visible only when writing new code
> (Core)? Will users know the difference?
I hope they'll first try to file in the SeaMonkey one when they're
filing a SeaMonkey bug, and not trying to file there if they're using a
different application.
The thing is that the old xpfe FAYT code is still used and built in
SeaMonkey, even on toolkit-based trunk builds, and has been renamed in
the code to "suitetypeaheadfind" to not clash with the toolkit
"typeaheadfind" component. So toolkit and SeaMonkey actually have two
separate parts of code for the same functionality but different
implementations (and different UI, which is the main reason for all
that). Bugzilla needs to reflect that, and I think this is the best way
to do it.
Robert Kaiser
Akkana Peck
> Akkana Peck wrote:
> > So it would be "Keyboard: Find in Page" and "Core: Find in Page"?
> > Or "Find in Page" and "Core: Find in Page"? Either way, there will
> > be two different categories with the same name?
>
> Yes, but it's "Core:: Find In Page" and "SeaMonkey:: Find In Page".
On http://www.gerv.net/temp/bmo-reorg.html now, I see three
components with the same name:
Seamonkey:: Keyboard: Find In Page
Components:: Core: Find in Page
Components:: Toolkit: Find in Page
It seems confusing to have three bug components with the same name
but referring to very different functionality. I can just see
trying to tell someone where to file a bug. "File that under 'Find
in Page' -- oh, but not the one in Seamonkey or the one in Core, be
sure to find the one for Firefox, but look for Toolkit, not Firefox.")
It would be clearer if they had different names, like
Seamonkey:: Keyboard: Find as you Type, or Fast Find
Components:: Core: Find Backend
Components:: Toolkit: Find Toolbar
> > what about bugs
> > on the Firefox widget that shows while you're doing a FAYT?
>
> That goes into the core one - clearly no SeaMonkey bug, right?
I realized after I posted that it would have been the old "Find Toolbar /
FastFind", so from the "moved from" on Gerv's page, I think now it's
"Components:: Toolkit: Find in Page".
> I hope they'll first try to file in the SeaMonkey one when they're
> filing a SeaMonkey bug, and not trying to file there if they're using a
> different application.
Makes sense, though in that case why isn't the Firefox find toolbar
under Firefox rather than Toolkit? Is it used in other apps?
Maybe the category for the find toolbar should be
Client Software:: Firefox : Find Toolbar
...Akkana
Robert Kaiser
> On http://www.gerv.net/temp/bmo-reorg.html now, I see three
> components with the same name:
>
> Seamonkey:: Keyboard: Find In Page
> Components:: Core: Find in Page
> Components:: Toolkit: Find in Page
Are you sure you aren't mixing up the left and right side?
I see two on both sides.
We're moving the Core component, which has the bugs about the xpfe
version, to SeaMonkey and creating a new one in Core for the new code.
Robert Kaiser
Jonas Sicking
My bad. That is indeed what I meant. So did you need any more info?
/ Jonas
Akkana Peck
> Akkana Peck wrote:
> > On http://www.gerv.net/temp/bmo-reorg.html now, I see three
> > components with the same name:
> >
> > Seamonkey:: Keyboard: Find In Page
> > Components:: Core: Find in Page
> > Components:: Toolkit: Find in Page
>
> Are you sure you aren't mixing up the left and right side?
I see three on the right side.
Highlight Proposed at the top of the right column, then do a FAYT
for find and you should see all three (plus of course the "moved
from" notes).
Even if there were only two, are identical names less confusing
if they are only twins rather than triplets?
...Akkana
Robert Kaiser
> Robert Kaiser wrote:
>> And "Keyboard: Find as you Type" should probably be name "Find In
>> Page", which matches the name for the parallel component in Core.
>
> Done.
Oh, umm, please also remove the "Keyboard:" prefix on that, it's not needed.
Robert Kaiser
Robert Kaiser
> Robert Kaiser writes:
>> Akkana Peck wrote:
>>> On http://www.gerv.net/temp/bmo-reorg.html now, I see three
>>> components with the same name:
>>>
>>> Seamonkey:: Keyboard: Find In Page
>>> Components:: Core: Find in Page
>>> Components:: Toolkit: Find in Page
>> Are you sure you aren't mixing up the left and right side?
>
> I see three on the right side.
Uh, right. That sounds plainly wrong. Core AND Toolkit and the same
doesn't make any sense at all.
> Even if there were only two, are identical names less confusing
> if they are only twins rather than triplets?
If it's SeaMonkey vs. Core OR Toolkit, I think it's the right thing.
Robert Kaiser
Gervase Markham
> My bad. That is indeed what I meant. So did you need any more info?
Nope. I've added a component called "Content" to Core.
Gerv
Gervase Markham
> Seamonkey:: Keyboard: Find In Page
> Components:: Core: Find in Page
> Components:: Toolkit: Find in Page
That's not quite right; it's (now):
Components / Toolkit / Find In Page
Components / Core / Find In Page
Client Software / SeaMonkey / Find In Page
The SeaMonkey one was moved from Core, so creating a new one in Core
does seem wrong. Can someone please decide what should happen here and
post a concrete, complete proposal?
Gerv