Last Call for b.m.o. reorganisation plan

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 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
0
Gervase
7/12/2007 4:16:45 PM
mozilla.dev.apps.thunderbird 3464 articles. 0 followers. Post Follow

93 Replies
902 Views

Similar Articles

[PageSpeed] 49

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
> 
> 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
0
fantasai
7/12/2007 5:36:51 PM
fantasai wrote:
> 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

0
Boris
7/12/2007 6:48:29 PM
Boris Zbarsky wrote:
> fantasai wrote:
>> 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?

http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/55b9096e56ef28d1/5eaddd0c3bf30766#5eaddd0c3bf30766

~fantasai
0
fantasai
7/12/2007 6:58:45 PM
fantasai wrote:
> 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

0
Boris
7/12/2007 7:09:40 PM
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

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

0
Dave
7/12/2007 7:34:27 PM
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.

-- 

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
0
David
7/12/2007 7:54:56 PM
On 2007-07-12 18:16 CET,
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
0
Rolf
7/12/2007 9:11:34 PM
On 2007-07-12 18:16 CET,
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
0
Rolf
7/12/2007 9:28:40 PM
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
> 
> 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.

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
0
Jonas
7/12/2007 10:15:19 PM
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
> 
> 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

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
0
Axel
7/12/2007 11:25:12 PM
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

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]
0
Steve
7/13/2007 3:29:56 AM
On Thu, 12 Jul 2007 20:29:56 -0700, Steve Wendt wrote:
> 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

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

All these issues have been extensively discussed in moz.dev.planning.

> 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

There are already equivalent components in /toolkit/. These "core"
components actually cover only SeaMonkey and date back to the time where
the only product from MoFo was the Mozilla Suite. Moving these to
SeaMonkey will reduce the number of cases of toolkit bugs wrongly filed
under these components.

> Similarly, can't most of Seamonkey's MailNews components be moved/merged 
> with the new MailNews Core components?

As KaiRo said, these need more discussion with the Thunderbird devs.

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

See the long discussions in mozilla.dev.planning for the whys and
wherefores.

Phil

-- 
Philip Chee <philip@aleytys.pc.my>, <philip.chee@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Like, I think my bottle absorbed my Beer, eh.
* TagZilla 0.066.6

0
Philip
7/13/2007 3:43:34 AM
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
> 
> 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

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)
0
Tony
7/13/2007 6:11:39 AM
Op Donderdag 12-07-2007 om 17:16 uur [tijdzone +0100], schreef Gervase
Markham:
> 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 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

Hi Gerv

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.

Keep well
Friedel

0
F
7/13/2007 6:57:52 AM
Gervase Markham wrote:
> 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
0
Samuel
7/13/2007 7:24:35 AM
F Wolff wrote:
> Op Donderdag 12-07-2007 om 17:16 uur [tijdzone +0100], schreef Gervase
> Markham:
>> 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 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
> 
> Hi Gerv
> 
> 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
0
Axel
7/13/2007 10:04:55 AM
Samuel Sidler wrote:
> Gervase Markham wrote:
>> 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

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
0
Axel
7/13/2007 10:20:55 AM
Steve Wendt wrote:
> 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

0
Robert
7/13/2007 4:17:23 PM
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

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

0
Robert
7/13/2007 4:25:43 PM
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".
> 
> 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.
0
Jean
7/13/2007 4:26:36 PM
Axel Hecht wrote:
> Samuel Sidler wrote:
>> Gervase Markham wrote:
>>> 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
> 
> 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

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
0
Samuel
7/13/2007 6:26:48 PM
On 7/13/07 2:26 PM, _Samuel Sidler_ spoke thusly:
> 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
0
Chris
7/13/2007 6:58:33 PM
Dave Townsend wrote:
> 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
0
Gervase
7/16/2007 11:02:50 AM
Boris Zbarsky wrote:
> 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
0
Gervase
7/16/2007 11:06:35 AM
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.

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
0
Gervase
7/16/2007 11:08:21 AM
Jean-Marc Desperrier wrote:
> 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
0
Gervase
7/16/2007 11:11:54 AM
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.

You need to get together with the relevant people and produce a concrete 
proposal.

Gerv
0
Gervase
7/16/2007 11:12:21 AM
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.

> 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
0
Gervase
7/16/2007 11:19:14 AM
Tony Mechelynck wrote:
> 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
0
Gervase
7/16/2007 11:22:10 AM
Robert Kaiser wrote:
> 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
0
Gervase
7/16/2007 11:24:26 AM
F Wolff wrote:
> 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
0
Gervase
7/16/2007 11:32:53 AM
Gervase Markham wrote:
> Tony Mechelynck wrote:
>> 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

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.
0
Tony
7/16/2007 11:37:09 AM
On 7/16/2007 4:08 AM, Gervase Markham wrote [in part]:
> 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".

-- 

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
0
David
7/16/2007 2:52:06 PM
David E. Ross wrote:
> 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
0
Gervase
7/16/2007 4:44:00 PM
Gervase Markham wrote:
> 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
0
Axel
7/16/2007 8:33:50 PM
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.
> 
> You need to get together with the relevant people and produce a concrete 
> proposal.

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
0
Jonas
7/16/2007 10:41:53 PM
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.
>>
>> You need to get together with the relevant people and produce a 
>> concrete proposal.
> 
> 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?

I guess you need the info that goes on the describecomponents list:

Default Asignee: nobody@mozilla.org
Default QA Contact: content@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
0
Jonas
7/16/2007 11:02:24 PM
On 7/17/07, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.
> >>
I hope the name "content" won't attract too many misguided bug filers,
as it happens in Firefox's part of bugzilla. Perhaps rename to
something less ambiguous (no specific ideas)?

Nickolay
0
Nickolay
7/16/2007 11:19:33 PM
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?

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
0
Akkana
7/17/2007 3:11:51 AM
Nickolay Ponomarev wrote:
> On 7/17/07, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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.
>> >>
> I hope the name "content" won't attract too many misguided bug filers,
> as it happens in Firefox's part of bugzilla. Perhaps rename to
> something less ambiguous (no specific ideas)?

Not really sure why "content" would be more attractive to filers than 
anything else? Maybe "Content model"?

/ Jonas
0
Jonas
7/17/2007 3:14:27 AM
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.

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
0
Gervase
7/17/2007 6:22:57 AM
Gervase Markham wrote:
> 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

0
Robert
7/17/2007 11:07:04 AM
Akkana Peck wrote:
> 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

0
Robert
7/17/2007 11:16:47 AM
Robert Kaiser writes:
> 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
0
Akkana
7/17/2007 5:59:43 PM
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 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

0
Robert
7/17/2007 6:49:30 PM
Gervase Markham wrote:
> 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.
> 
> 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 :-)

My bad. That is indeed what I meant. So did you need any more info?

/ Jonas
0
Jonas
7/17/2007 8:48:23 PM
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.

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
0
Akkana
7/18/2007 2:30:52 AM
Gervase Markham wrote:
> 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

0
Robert
7/18/2007 11:09:14 AM
Akkana Peck wrote:
> 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

0
Robert
7/18/2007 11:12:14 AM
Jonas Sicking wrote:
> 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
0
Gervase
7/18/2007 6:11:57 PM
Akkana Peck wrote:
> 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
0
Gervase
7/18/2007 6:16:02 PM
Gervase Markham wrote:
> 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?

So we definitely need "Toolkit::Find In Page" [moved from Firefox; 
renamed from Find Toolbar / FastFind]. The backend code lives in
http://mxr.mozilla.org/seamonkey/source/toolkit/components/typeaheadfind/ 
and the find toolbar frontend in
http://mxr.mozilla.org/seamonkey/source/toolkit/content/widgets/findbar.xml.
It is used by e.g. Firefox and Thunderbird.

The other (older) implementation lives in 
http://mxr.mozilla.org/seamonkey/source/extensions/typeaheadfind/. The 
module calls itself "suitetypeaheadfind" and is used by both Seamonkey 
and Camino.
So we could have "Core::Find in Page", because it's shared between 
Seamonkey and Camino. But that's problematic because someone wanting to 
file a bug on Firefox's find toolbar might not know whether to file in 
Core or Toolkit. And the Seamonkey project is much more likely to 
maintain that code.

So I propose to move "Core::Keyboard: Find As You Type" to "Seamonkey: 
Find in Page" (like already planned) and remove "Core::Find In Page" [new].

Result:
Firefox::Find in Page
Seamonkey::Find in Page

Steffen
0
Steffen
7/18/2007 7:14:35 PM
Steffen Wilberg writes:
> So I propose to move "Core::Keyboard: Find As You Type" to "Seamonkey: 
> Find in Page" (like already planned) and remove "Core::Find In Page" [new].
> 
> Result:
> Firefox::Find in Page
> Seamonkey::Find in Page

Even though I've been arguing against having multiple components with
the same name, that makes sense since they're each prefaced by a
specific application. I don't think that would confuse anyone.

But what about bugs in the backend nsFind code? I thought that was
what the Core component was for. Is there some other component that
inherits those bugs now?

If not, I propose "Core::Find Backend" for nsFind bugs.
(In addition to your two "AppName::Find in Page"s.)

	...Akkana
0
Akkana
7/18/2007 9:10:54 PM
Akkana Peck wrote:
> But what about bugs in the backend nsFind code? I thought that was
> what the Core component was for. Is there some other component that
> inherits those bugs now?
Either the front-end components "AppName::Find in Page", or 
"Core::General", I guess.

> If not, I propose "Core::Find Backend" for nsFind bugs.
> (In addition to your two "AppName::Find in Page"s.)
nsFind.cpp and nsWebBrowserFind.cpp each have around 50 revisions, and a 
lot of those are due to tree-wide cleanup like deCOMtamination. How many 
bugs do you expect to be in that component?

Steffen
0
Steffen
7/18/2007 10:43:55 PM
Akkana Peck wrote:
> Steffen Wilberg writes:
>> So I propose to move "Core::Keyboard: Find As You Type" to "Seamonkey: 
>> Find in Page" (like already planned) and remove "Core::Find In Page" [new].
>>
>> Result:
>> Firefox::Find in Page
>> Seamonkey::Find in Page
> 
> Even though I've been arguing against having multiple components with
> the same name, that makes sense since they're each prefaced by a
> specific application. I don't think that would confuse anyone.

So, bugs in the find bar of SeaMonkey's help window, which is a toolkit 
help window and uses the toolkit FAYT implementation, will end up in 
Firefox once again? Nice.

Well, that case is bad for users in any case. But the toolkit/ FAYT is a 
XULRunner component available in all toolkit apps, so it should not live 
in any app-specific Bugzilla product. Toolkit is right for that.

Camino should move away from all xpfe stuff soon (hell, I'd love to 
break xpfe so much that they really have to do it) and then SeaMonkey is 
the only user of suitetypeaheadfind, so it should really live in the 
SeaMonkey product.

Needing two FAYT implementations in SeaMonkey is bad enough anyways, but 
I see no way around it atm.

Robert Kaiser

0
Robert
7/19/2007 12:29:57 AM
Steffen Wilberg writes:
> Akkana Peck wrote:
> > If not, I propose "Core::Find Backend" for nsFind bugs.
> nsFind.cpp and nsWebBrowserFind.cpp each have around 50 revisions, and a 
> lot of those are due to tree-wide cleanup like deCOMtamination. How many 
> bugs do you expect to be in that component?

There are quite a few bugs already filed against the nsFind backend.
Mostly RFEs, actually, dealing with things like i18n, find whole
word, finding in XML documents, and finding in form elements like
text fields and buttons. A bugzilla search for Find in the longdesc
found lots of them (as well as bugs on the various front-ends).
I found 14 backend bugs/RFEs by the time I stopped counting about
a quarter of the way through the search results.

But I guess they've never been together before, and it turns out
there's currently no easy way to find such bugs -- they're all over
the map in terms of their assigned Component though most are
in the product "Mozilla Application Suite". At one point there was a
tracking bug (106961, in Component editor) but I'm sure it's outdated.

If we did have a component for nsFind I'd be willing to try to find
bugs that belong there and reassign them, but I guess if we didn't
have one before, it may not be worth creating one now.

Robert Kaiser writes:
> Well, that case is bad for users in any case. But the toolkit/ FAYT is a 
> XULRunner component available in all toolkit apps, so it should not live 
> in any app-specific Bugzilla product. Toolkit is right for that.

That was my earlier question -- whether it was used anywhere
other than Firefox. Since it is, then Toolkit makes sense for it.
But in that case, surely giving it the same name as the Suite's
version is just asking for misfiled bugs, especially when people
file bugs on the suite's use of the Toolkit toolbar. Calling it
"Find Toolbar" makes more sense than calling it "Find in Page"
if the toolkit toolbar is what's being covered.

	...Akkana
0
Akkana
7/19/2007 2:51:51 AM
Steffen Wilberg wrote:
> Result:
> Firefox::Find in Page
> Seamonkey::Find in Page

Oh crap!! That should've been
Toolkit::Find in Page (the code lives in toolkit/ and is used by 
Thunderbird as well)
Semonkey::Find in Page

I'm sorry for the confusion.

Steffen
0
Steffen
7/19/2007 6:49:01 PM
Robert Kaiser wrote:
> Akkana Peck wrote:
>> Steffen Wilberg writes:
>>> So I propose to move "Core::Keyboard: Find As You Type" to 
>>> "Seamonkey: Find in Page" (like already planned) and remove 
>>> "Core::Find In Page" [new].
>>>
>>> Result:
>>> Firefox::Find in Page
>>> Seamonkey::Find in Page
>>
>> Even though I've been arguing against having multiple components with
>> the same name, that makes sense since they're each prefaced by a
>> specific application. I don't think that would confuse anyone.
> 
> So, bugs in the find bar of SeaMonkey's help window, which is a toolkit 
> help window and uses the toolkit FAYT implementation, will end up in 
> Firefox once again? Nice.
Sorry for having this messed up. I wanted to propose
Toolkit::Find in Page and Seamonkey::Find in Page.

> Well, that case is bad for users in any case. But the toolkit/ FAYT is a 
> XULRunner component available in all toolkit apps, so it should not live 
> in any app-specific Bugzilla product. Toolkit is right for that.
Of course. I even proposed to move Firefox::Find Toolbar to Toolkit 
originally.

> Needing two FAYT implementations in SeaMonkey is bad enough anyways, but 
> I see no way around it atm.
You should really switch to the find toolbar ;-)

Steffen
0
Steffen
7/19/2007 6:58:44 PM
Akkana Peck wrote:
> If we did have a component for nsFind I'd be willing to try to find
> bugs that belong there and reassign them, but I guess if we didn't
> have one before, it may not be worth creating one now.
Would you also willing to fix some of them? I guess you still know the 
code, being the initial developer ;-)

I'd say if someone is interested in these bugs and would watch the 
component, it's worth to keep the proposed new Core::Find in Page 
component, but call it Core::Find Backend to reduce confusion.

> Calling it
> "Find Toolbar" makes more sense than calling it "Find in Page"
> if the toolkit toolbar is what's being covered.
The toolkit implementation is indeed the find toolbar.
The code is 
http://mxr.mozilla.org/seamonkey/source/toolkit/content/widgets/findbar.xml, 
but also 
http://mxr.mozilla.org/seamonkey/source/toolkit/components/typeaheadfind/.

But I don't know that code and have no idea if and how that code 
interacts with nsFind.cpp...

Steffen
0
Steffen
7/19/2007 7:16:41 PM
Steffen Wilberg wrote:
> You should really switch to the find toolbar ;-)

Except that it's not as usable... other than that, sure.  :)

-Boris

0
Boris
7/19/2007 7:22:31 PM
Steffen Wilberg wrote:
>> If we did have a component for nsFind I'd be willing to try to find
>> bugs that belong there and reassign them, but I guess if we didn't
>> have one before, it may not be worth creating one now.

Note that in the past we've had to stick bugs that belonged there in random 
places as a result.  I did bring up the need for a core find component for this 
code earlier in this thread.  no idea what happend to it.

> component, but call it Core::Find Backend to reduce confusion.

That seems like a perfectly good name.

> But I don't know that code and have no idea if and how that code 
> interacts with nsFind.cpp...

"badly", for the most part.

-Boris

0
Boris
7/19/2007 7:24:15 PM
Boris Zbarsky wrote:
> Steffen Wilberg wrote:
>> You should really switch to the find toolbar ;-)
> 
> Except that it's not as usable... other than that, sure.  :)
What do you miss? It's even got Highlight all.

Steffen
0
Steffen
7/19/2007 7:30:00 PM
OK, so let's do this:
1. Firefox::Find Toolbar / FastFind becomes Toolkit::Find Toolbar.
    That's the toolkit (Firefox, Thunderbird etc.) front-end.
2. Core::Keyboard: Find As You Type becomes SeaMonkey::Find in Page.
    That's the SeaMonkey front-end.
3. create a new Core::Find Backend component.
    That's the common back-end.

Steffen
0
Steffen
7/19/2007 7:49:59 PM
Steffen Wilberg wrote:
> Robert Kaiser wrote:
>> Needing two FAYT implementations in SeaMonkey is bad enough anyways, 
>> but I see no way around it atm.
> You should really switch to the find toolbar ;-)

Except that we dislike that find bar UI big time. Even our poor status 
bar feedback is UI that most people in our team like better.

IMHO, a bar at the bottom of the window is very non-intuitive.

Robert Kaiser

0
Robert
7/19/2007 9:52:40 PM
Robert Kaiser wrote:
> Steffen Wilberg wrote:
>   
>> Robert Kaiser wrote:
>>     
>>> Needing two FAYT implementations in SeaMonkey is bad enough anyways, 
>>> but I see no way around it atm.
>>>       
>> You should really switch to the find toolbar ;-)
>>     
>
> Except that we dislike that find bar UI big time. Even our poor status 
> bar feedback is UI that most people in our team like better.
>
> IMHO, a bar at the bottom of the window is very non-intuitive.
>
> Robert Kaiser
You could put it at the top of the page for Accel+F, its a widget now.  
There's also been a discussion about using the statusbar for FAYT by 
default, this would be preffable.  Seems much saner to work on making 
the one impl flexible enough to work, rather than carrying around two 
fayt impls indefinitely.

-- Mike
0
Mike
7/19/2007 10:28:03 PM
Mike Connor wrote:
> You could put it at the top of the page for Accel+F, its a widget now.  
> There's also been a discussion about using the statusbar for FAYT by 
> default, this would be preffable.  Seems much saner to work on making 
> the one impl flexible enough to work, rather than carrying around two 
> fayt impls indefinitely.

This is all true.

Last I checked, when the toolkit impl got forked off the then-current suite one, 
a lot of flexibility got ripped out as being "unnecessary".  I haven't paid much 
attention to either set of code much, but those who have might have a good idea 
of which impl is easier to extend to cover all the use cases we want.

I do think we want a single, well-owned, impl in preference to the two 
badly-owned ones we have now.

-Boris

0
Boris
7/20/2007 4:01:35 AM
Mike Connor wrote:
> Seems much saner to work on making 
> the one impl flexible enough to work, rather than carrying around two 
> fayt impls indefinitely.

I'm fully with you on that, but I don't think we really know what kind 
of UI we prefer.
Most of our people like the statusbar feedback for real FAYT, but this 
isn't a solution for Edit > Find in this Page and also no accessible 
solution or Japanese/Chinese-friendly solution - and I for myself am not 
satisfied with the current solutions, I'm more leaning towards a 
multi-mode urlbar that also does that, though I'm not yet sure how to do 
that in a way that normal users don't get confused.

Robert Kaiser

0
Robert
7/24/2007 1:10:28 PM
Robert Kaiser wrote:
> Mike Connor wrote:
>> Seems much saner to work on making the one impl flexible enough to 
>> work, rather than carrying around two fayt impls indefinitely.
> 
> I'm fully with you on that, but I don't think we really know what kind 
> of UI we prefer.
> Most of our people like the statusbar feedback for real FAYT, but this 
> isn't a solution for Edit > Find in this Page and also no accessible 
> solution or Japanese/Chinese-friendly solution - and I for myself am not 
> satisfied with the current solutions, I'm more leaning towards a 
> multi-mode urlbar that also does that, though I'm not yet sure how to do 
> that in a way that normal users don't get confused.
> 
> Robert Kaiser
> 

The URL bar is already overloaded as it is, doubling (in SeaMonkey, not in 
Firefox) as a Search bar for the default engine; and (at least in Minefield) 
as a widget of dubious utility (to say the least) to almost-hide everything 
but the domain when not focused.

For searching, I favour something separate, be it the status bar (as currently 
in SeaMonkey), a popup toolbar (as currently just above the status bar in 
Firefox) or even a plain popup in the middle of the screen (as in most 
non-Mozilla programs).


Best regards,
Tony.
-- 
FATHER:    You killed eight wedding guests in all!
LAUNCELOT: Er, Well ... the thing is ... I thought your son was a lady.
FATHER:    I can understand that.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
0
Tony
7/24/2007 7:46:51 PM
----- "Gervase Markham" <gerv@mozilla.org> wrote:
> F Wolff wrote:
> > 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.

OK my perspective on the history is as follows:

Northern Sotho is not a variant of Southern Sotho which is properly called Sesotho.
There were a variety of related languages in the Northern region which the apartheid government decided would be classified into one language. These are probably on the borderline of the language/dialect distinction but making one language of them all was a stretch motivated politically. They called this official language "Northern Sotho"
Of the different dialects/languages the most prominent one and the one that has been standardised for the language is called Sepedi (or Pedi if you drop the suffix). So if you ask people what they speak they will say Sepedi.

So up to you as to what you judge - I'd incline more towards calling it Sepedi (Northern Sotho)

Cheers
David
0
David
8/9/2007 7:52:08 AM
David Fraser wrote:
> Northern Sotho is not a variant of Southern Sotho which is properly
> called Sesotho. 
<snip>

This is clearly a minefield. So I've done the minimum to make it look 
OK, given that I assume the current names are acceptable to the teams 
concerned.

Before:
nso / Northern Sotho/Pedi
st / Southern Sotho

Now:
nso / Northern Sotho (Pedi)
st / Southern Sotho

I hope no-one objects too much to this :-)

Gerv
0
Gervase
8/15/2007 10:27:54 AM
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

I have a question about theme bugs.  We apparently have some "toolkit" themes, 
in addition to various per-front-end themes (browser, suite, whatever).  I don't 
see a place for bugs in those to go in the proposed setup (currently I'd put 
them in Core:Themes).

-Boris

0
Boris
8/19/2007 5:54:50 PM
On 8/19/2007 10:54 AM, Boris Zbarsky wrote:
> 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
> 
> I have a question about theme bugs.  We apparently have some "toolkit" themes, 
> in addition to various per-front-end themes (browser, suite, whatever).  I don't 
> see a place for bugs in those to go in the proposed setup (currently I'd put 
> them in Core:Themes).
> 
> -Boris
> 

Themes are part of user interfaces.  Further, I think some are specific
to a particular product (e.g., either Firefox or SeaMonkey but not
both).  Perhaps there should be a theme category under each "Client
Software" product for which themes can exist.

-- 

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
0
David
8/19/2007 8:53:12 PM
David E. Ross wrote:
> Themes are part of user interfaces.   Further, I think some are specific
> to a particular product (e.g., either Firefox or SeaMonkey but not
> both).  Perhaps there should be a theme category under each "Client
> Software" product for which themes can exist.

Sure.  Again, I'm more interested in the "core toolkit" themes that all products 
share, since I'm not likely to be filing bugs in the per-product ones that 
much....  But we do need a place for the per-product bugs too.

-Boris

0
Boris
8/19/2007 8:59:44 PM
There hasn't been opposition to this very last proposal concerning Find 
Toolbar/Find in Page/Find Backend. I'd suggest to update the 
reorganisation plan accordingly.

Steffen


Steffen Wilberg wrote:
> OK, so let's do this:
> 1. Firefox::Find Toolbar / FastFind becomes Toolkit::Find Toolbar.
>    That's the toolkit (Firefox, Thunderbird etc.) front-end.
> 2. Core::Keyboard: Find As You Type becomes SeaMonkey::Find in Page.
>    That's the SeaMonkey front-end.
> 3. create a new Core::Find Backend component.
>    That's the common back-end.
> 
> Steffen
0
Steffen
8/19/2007 9:47:55 PM
There hasn't been opposition to this very last proposal concerning Find 
Toolbar/Find in Page/Find Backend. I'd suggest to update the 
reorganisation plan accordingly.

Steffen


Steffen Wilberg wrote:
> OK, so let's do this:
> 1. Firefox::Find Toolbar / FastFind becomes Toolkit::Find Toolbar.
>    That's the toolkit (Firefox, Thunderbird etc.) front-end.
> 2. Core::Keyboard: Find As You Type becomes SeaMonkey::Find in Page.
>    That's the SeaMonkey front-end.
> 3. create a new Core::Find Backend component.
>    That's the common back-end.
> 
> Steffen
0
Steffen
8/19/2007 9:48:17 PM
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
> 
> 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

Do we have any idea when the reorg is actually going to happen?

Dave
0
Dave
8/23/2007 11:06:03 AM
Dave Townsend wrote:
> Do we have any idea when the reorg is actually going to happen?

We want to do it all at once; but before we can move components between 
products, a script needs to be developed to do that, as Bugzilla doesn't 
do it through the UI. Also, if we are renaming so many components, we 
probably need a script to fix up stored queries and charts.

These are on my ToDo list. Of course, if a Bugzilla hacker wants to step 
in and help...

Gerv
0
Gervase
8/29/2007 3:34:53 PM
Boris Zbarsky wrote:
> 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
> 
> I have a question about theme bugs.  We apparently have some "toolkit" 
> themes, in addition to various per-front-end themes (browser, suite, 
> whatever).  I don't see a place for bugs in those to go in the proposed 
> setup (currently I'd put them in Core:Themes).

Is this an existing problem, or one created by the reorg?

I need concrete, clear proposals if any changes are going to be made.

Gerv
0
Gervase
8/29/2007 3:35:28 PM
Gervase Markham wrote:
> Dave Townsend wrote:
>> Do we have any idea when the reorg is actually going to happen?
> 
> We want to do it all at once; but before we can move components between 
> products, a script needs to be developed to do that, as Bugzilla doesn't 
> do it through the UI. Also, if we are renaming so many components, we 
> probably need a script to fix up stored queries and charts.
> 
> These are on my ToDo list. Of course, if a Bugzilla hacker wants to step 
> in and help...

For this reason we discussed in the Gecko meeting that we might want to 
hold off on this until after the 1.9 release. Otherwise we're screwing 
up all queries spread out everywhere that we use to keep track of 
blocker lists, approval requests, bug counts etc.

/ Jonas
0
Jonas
8/29/2007 6:47:33 PM
Gervase Markham wrote:
> Is this an existing problem, or one created by the reorg?

The former.

> I need concrete, clear proposals if any changes are going to be made.

We need a Themes component in some shared product for these themes.  Either 
Toolkit or Core.  I have no preference as to which; the people who actually deal 
with this code should comment.

-Boris

0
Boris
8/29/2007 7:28:56 PM
Boris Zbarsky wrote:
> Gervase Markham wrote:
>> Is this an existing problem, or one created by the reorg?
> 
> The former.
> 
>> I need concrete, clear proposals if any changes are going to be made.
> 
> We need a Themes component in some shared product for these themes.  
> Either Toolkit or Core.  I have no preference as to which; the people 
> who actually deal with this code should comment.

Well, any time I asked toolkit people about something like that, they 
said "file theme bugs in the component for the part of the code it 
belongs to", i.e. widget theming wherever the widget bugs belong, etc.

Robert Kaiser

0
Robert
8/29/2007 11:39:41 PM
Jonas Sicking wrote:
> For this reason we discussed in the Gecko meeting that we might want to 
> hold off on this until after the 1.9 release. Otherwise we're screwing 
> up all queries spread out everywhere that we use to keep track of 
> blocker lists, approval requests, bug counts etc.

Hrm, and while waiting those few months, we probably get another few 
thousand bugs filed in obsolete and wrong components while the new 
structure would probably lead people to more easily find the right 
components.
And we'll probably get a few dozen more "Umm, so where to file SeaMonkey 
bugs?" requests because the product is still called "Mozilla Application 
Suite".

I guess none of the options is ideal.

Robert Kaiser

0
Robert
8/29/2007 11:57:02 PM
Robert Kaiser wrote:
> Well, any time I asked toolkit people about something like that, they 
> said "file theme bugs in the component for the part of the code it 
> belongs to", i.e. widget theming wherever the widget bugs belong, etc.

That doesn't work for toolkit themes used from Core code, because they need UI 
review and there is no such flag in Core.

-Boris


0
Boris
8/30/2007 1:43:49 AM
On Wed, 29 Aug 2007 20:43:49 -0500
Boris Zbarsky <bzbarsky@mit.edu> wrote:

> That doesn't work for toolkit themes used from Core code, because
> they need UI review and there is no such flag in Core.

That can be remedied, if needed. :)

~reed

-- 
Reed Loden - <reed@reedloden.com>
0
Reed
8/30/2007 2:50:49 AM
Reed Loden wrote:
> That can be remedied, if needed. :)

I think the right remedy is to add a Toolkit:Themes and make sure there's a 
ui-review in Toolkit.

-Boris

0
Boris
8/30/2007 3:03:13 AM
Jonas Sicking wrote:
> For this reason we discussed in the Gecko meeting that we might want to 
> hold off on this until after the 1.9 release. Otherwise we're screwing 
> up all queries spread out everywhere that we use to keep track of 
> blocker lists, approval requests, bug counts etc.

Presumably you mean queries not stored in Bugzilla itself, right? As I 
said, we plan to fix these.

The 1.9 release could easily be six months away. That's a very long wait.

Gerv
0
Gervase
8/30/2007 9:53:52 AM
hi;

ummm... are you talking about holding b.m.o changes for *all* 
components, or only the FF3 components using bug metrics at this point 
of the 1.9 release?

My recollection was that, for all components tracking metrics for FF3, 
the b.m.o cleanup would not happen yet. This was to not throw off 
previous QA numbers. However, for other components, I thought we agreed 
it was ok to go ahead with the b.m.o cleanup?

But it was a while ago, so I'm looking for clarification...


tc
John.
=====
Robert Kaiser wrote:
> Jonas Sicking wrote:
>> For this reason we discussed in the Gecko meeting that we might want to 
>> hold off on this until after the 1.9 release. Otherwise we're screwing 
>> up all queries spread out everywhere that we use to keep track of 
>> blocker lists, approval requests, bug counts etc.
> 
> Hrm, and while waiting those few months, we probably get another few 
> thousand bugs filed in obsolete and wrong components while the new 
> structure would probably lead people to more easily find the right 
> components.
> And we'll probably get a few dozen more "Umm, so where to file SeaMonkey 
> bugs?" requests because the product is still called "Mozilla Application 
> Suite".
> 
> I guess none of the options is ideal.
> 
> Robert Kaiser
> 
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
0
John
8/30/2007 10:16:15 AM
John O'Duinn wrote:
> hi;
> 
> ummm... are you talking about holding b.m.o changes for *all* 
> components, or only the FF3 components using bug metrics at this point 
> of the 1.9 release?
> 
> My recollection was that, for all components tracking metrics for FF3, 
> the b.m.o cleanup would not happen yet. This was to not throw off 
> previous QA numbers. However, for other components, I thought we agreed 
> it was ok to go ahead with the b.m.o cleanup?
> 
> But it was a while ago, so I'm looking for clarification...

I've never been in such a meeting, I'm only replying on what Jonas said 
here. Regarding your statement, I wonder where that line of doing the 
reorg or not would be drawn though, and if it's OK to break some queries 
people have locally at least two times when slitting apart those changes.

Given that 1.9 final seems to be at least 3 months away (November was 
the original plan, AFAIK, even if I don't believe we'll make that), I 
think now would be a good time to make a clear cut.
Most FF3 metrics might not be affected that much anyways, as one can map 
old components to new ones in pretty much all areas that affect Firefox. 
And per-product metrics are wrong at the moment anyways, as a bunch of 
components are in the wrong products right now, so which will be 
corrected by the reorg.

Robert Kaiser

0
Robert
8/30/2007 10:26:16 AM
Gervase Markham wrote:
> Dave Townsend wrote:
>> Do we have any idea when the reorg is actually going to happen?
> 
> We want to do it all at once; but before we can move components between
> products, a script needs to be developed to do that, as Bugzilla doesn't
> do it through the UI. Also, if we are renaming so many components, we
> probably need a script to fix up stored queries and charts.

It's been so long ... can someone refresh my memory about what we finally
decided to do for a "not our bug" resolution?

0
Nelson
8/31/2007 1:19:55 AM
Nelson Bolyard wrote:
> It's been so long ... can someone refresh my memory about what we finally
> decided to do for a "not our bug" resolution?

I think we decided that, having added INCOMPLETE as a resolution, we 
could get by with that, INVALID and the others. But I could be 
misremembering.

Gerv
0
Gervase
8/31/2007 9:01:35 AM
Gervase Markham wrote:
> David Fraser wrote:
>   
>> Northern Sotho is not a variant of Southern Sotho which is properly
>> called Sesotho. 
>>     
> <snip>
>
> This is clearly a minefield. So I've done the minimum to make it look 
> OK, given that I assume the current names are acceptable to the teams 
> concerned.
>
> Before:
> nso / Northern Sotho/Pedi
> st / Southern Sotho
>
> Now:
> nso / Northern Sotho (Pedi)
> st / Southern Sotho
>
> I hope no-one objects too much to this :-)
Looks good, thanks Gerv
David
0
David
8/31/2007 10:25:08 AM
Gervase Markham wrote:
> Jonas Sicking wrote:
>> For this reason we discussed in the Gecko meeting that we might want 
>> to hold off on this until after the 1.9 release. Otherwise we're 
>> screwing up all queries spread out everywhere that we use to keep 
>> track of blocker lists, approval requests, bug counts etc.
> 
> Presumably you mean queries not stored in Bugzilla itself, right? As I 
> said, we plan to fix these.

How are you planning on fixing these? Many of these queries are based on 
filtering by component, some of these components are being merged or 
moved elsewhere. This seems very hard to deal with manually while being 
sure that the right components are used in the right queries.

/ Jonas
0
Jonas
9/6/2007 3:45:27 AM
Jonas Sicking wrote:
> How are you planning on fixing these? Many of these queries are based on 
> filtering by component, some of these components are being merged or 
> moved elsewhere. This seems very hard to deal with manually while being 
> sure that the right components are used in the right queries.

We plan to parse the query strings stored in the database and replace 
old component names with new ones.

If there are duplicate component names, of course, this won't always be 
possible, but we can fix most of them.

The alternative is asking people to fix them up themselves.

Gerv
0
Gervase
9/6/2007 10:44:56 AM
Reply:

Similar Artilces:

[b.m.o] No votes for Thunderbird
I seem not to be able to vote for bugs filed in the Thunderbird product. Is this intentional? -Bene -- Benedikt Kantus on a Thumperbunny nightly At 5:40 PM +0100 1/28/2004, Benedikt Kantus (formerly bkantus@web.de) wrote: > I seem not to be able to vote for bugs filed in the Thunderbird product. > > Is this intentional? No clue. You might try asking in one of the Thunderbird newsgroups. (But yes, I can see their "maxvotes" is set to 0) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://w...

A S A E r r o r
Hi, I am trying to add a column through java to the table "acms_program" that is already part of publication. My Java Code tries to execute the below SQL statements 1. alter publication dba.apollo_code_status delete table acms_program; 2. alter table dba.acms_program add test_column varchar(20); 3.alter publication dba.apollo_code_status add table acms_program; Java code is able to excute the first statement successfuly and deleting table from publication. But it gives "table must be empty" when it tries to execute the add column stement. please help...

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current b #2
Josh Aas <joshmoz@gmail.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ------- Additional Comments from Josh Aas <joshmoz@gmail.com> I know mark isn't sr, but I want him to review this and I can't request another normal review via flags... I suspect this won't be as sa...

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current b #3
Josh Aas <joshmoz@gmail.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ...

a.m.o and thunderbird
I just updated two of my extensions to work with thunderbird. They install and work. But, when I submit the new file to a.m.o, it says "Thunderbird N/A" instead of the versions I indicated in install.rdf. Have I done something wrong? XPIs: http://arantius.com/misc/firefox-extensions/mine/moretools-1.0.6.xpi http://arantius.com/misc/firefox-extensions/mine/tinymenu-1.2.5.xpi ...

C.H.E.A.P.....M.A.R.L.B.O.R.O.... ....Ozh8H6Q4X
Some cheap marlboro sites http://www.google.com/search?q=new%20marlboro%20cigarettes&hl=en ....... you won't hate me talking with your younger bathroom I am smartly rural, so I fill you. If the kind tickets can talk bimonthly, the heavy desk may irritate more cafes. Are you new, I mean, fearing against dull lemons? I was seeking to judge you some of my sweet smogs. Oris, have a urban floor. You won't climb it. He'll be moving at pathetic Kaye until his wrinkle nibbles easily. While shoes loudly grasp jackets, the pitchers often live alongside the angry b...

b.m.o templates
Hi, I really like the look of the layout of bugzilla.mozilla.org, I think there are several things that make it more readable than the "standard" bugzilla install. The stock commands on the top. The layout of the standard bug page -- with the # and description right up top, and status/resolution combined, and the comment box at the very bottom after the comments. Where can I find these custom templates? Thanks. -Alex Alex Pavloff wrote: > Where can I find these custom templates? I'll answer myself -- in Bugzilla 3.0! Duh! -Alex ...

Testimonials in b.m.o
In October 2003 a bug was created for a 'Success stories / testimonials project'. https://bugzilla.mozilla.org/show_bug.cgi?id=223355 Is this still needed seven years later? Do these bugs need to remain open? https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc=Testimonial:&short_desc_type=allwordssubstr -- John Vandenberg ...

Posting to graphs.m.o instead of graphs-old.m.o
Hi all, As of this morning we are posting to graphs.mozilla.org rather than graphs-old.mozilla.org. This means that the tbpl links to graphs will lead you to the new graph server rather than the old one. This: http://graphs.mozilla.org/graph.html#tests=[[163,131,14]] vs this: http://graphs-old.mozilla.org/graph.html#tests=[{%22test%22:163,%22branch%22:131,%22machine%22:1311}] Let us know if you see any fallouts from it in bug https://bugzilla.mozilla.org/show_bug.cgi?id=728271 Best regards, Armen ...

Test Plan for Thunderbird 17
Hi Thunderbird developers , users and testers, Thunderbird 17 release is approaching quickly (eg Nov. 20th). And according to the future release plans, this release should be used until gecko 24 is ready. In order to have a kick ass release (free of as much possible regressions), I want to propose the following test plan : * Have a test week during Aurora (eg starting Next Sunday) * Have a second test week when we reach beta 1 * Have as many users as possible running 17 until it get's released To achieve that I'll need *YOU* to invest some time into testing Thunderbir...

Question about boolean charts at b.m.o
Hi, I'm trying to save a search at bmo relating to the next Bugzilla release, and it's returning more rows than I'd like. The criteria are supposed to be: Product Bugzilla, and ((blocking 2.20.1+) or (blocking 2.18.4+) or (blocks 320306)) and ((Status is unresolved) or (Days since bug changed < 6)) The intent is to get either release blockers, or bugs blocking the release-tracker bug (relnotes, etc.), where they are either open or resolved within the last 5 days (so I can see which ones were recently closed). The URL for the search is: https://bugzilla....

App manager and Dev Apps
Hello, I am experiencing problems to debug apps loaded in the App Manager. I don't have this problem if the App is downloaded from the Marketpalce and debugged with the App Manager. Is there a known problem to debug Dev Apps, loaded from a directory in your computer? Thanks, Juanma ...

Redirecting P R O B L E M
Name: Zara Email: little_angels23athotmaildotcom Product: Firefox Summary: Redirecting P R O B L E M Comments: Everytime i click on a website link (on google etc.) the website opens in a new tab. Not only this but now in the new tab the website is redirected to rubbish search engines (www.blinkx.com, www.mamma.com) which won't let me get back to the original website link i clicked on. Everytime this happens results.ask.com comes up as well and i think this is what redirects the page. This is incredibly annoying and it takes ages to load and to get back to the original pa...

Dev recommendations on MDN App Center: call for feedback on UX
Hi all, Liz (cc=92d) and I have done some work on dev recommendations[1] for the = MDN App Center[2], specifically thinking about the UX of these = recommendations - how they will be presented on App Center subpages. Essentially, we want to provide developers with recommendations on how = to understand a topic to solve a problem as quickly as possible, without = having to wade through tonnes of tutorials/guides. Think =93My boss = wants me to implement this in a week. I just need a solution that = works.=94 I produced a prototype[3] to show what kind of thing we were = after. We p...

Web resources about - Last Call for b.m.o. reorganisation plan - mozilla.dev.apps.thunderbird

States Reorganisation Act, 1956 - Wikipedia, the free encyclopedia
The States Reorganisation Act, 1956 was a major reform of the boundaries of India 's states and territories , organising them along linguistic ...

Cabinet announces reorganisation after Finance Minister Merz was taken ill - swissinfo.ch
Justice Minister Eveline Widmer-Schlumpf has taken over the finance portfolio ad interim after the incumbent Hans-Rudolf Merz suffered a heart ...

Microsoft to cut 18,000 jobs in major reorganisation - Business Recorder
Microsoft''s new chief Thursday unveiled the biggest job cuts ever at the US tech giant, aiming for a new strategic direction while integrating ...

Lok Sabha passes Andhra Pradesh Reorganisation Bill
The Lok Sabha Friday passed the Andhra Pradesh Reorganisation (Amendment) Bill 2014 amid protests from members of the Telangana Rashtra Samithi ...

Occupy Central not reason behind Li Ka-shing's reorganisation of business ...
Occupy Central not reason behind Li Ka-shing's reorganisation of business ... South China Morning Post (subscription) Billionaire Li Ka-shing's ...

Rostelecom completes second stage of Svyazinvest reorganisation
TeleGeography’s free daily email summary of the world’s top telecom news stories.

CIA chief announces sweeping reorganisation of US spy agency
Director John Brennan has ordered a sweeping reorganisation of the CIA, an overhaul designed to make its leaders more accountable and close espionage ...

Why Apple's reorganisation spells the unification of iOS and OS X
The pieces are now in place for Apple to bring together its mobile and desktop operating systems - a move that will be a no-brainer if Windows ...

Fiat gets green light for global reorganisation - Oman Observer
TURIN, Italy — Fiat shareholders have approved the reorganisation of the Italian carmaker’s business that will see its headquarters move to the ...

Microsoft unveils reorganisation
Microsoft chief executive Steve Ballmer announces a restructuring in what is the first major overhaul of the company in five years.

Resources last updated: 12/30/2015 4:13:12 AM