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
Steffen Wilberg
> 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
Akkana Peck
> 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
Steffen Wilberg
> 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?
"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
Robert Kaiser
> 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
Akkana Peck
> Akkana Peck wrote:
> > If not, I propose "Core::Find Backend" for nsFind bugs.
> 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
Steffen Wilberg
> 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
Steffen Wilberg
> 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.
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
Steffen Wilberg
> 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.
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
Boris Zbarsky
> You should really switch to the find toolbar ;-)
Except that it's not as usable... other than that, sure. :)
-Boris
Boris Zbarsky
>> 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
Steffen Wilberg
Steffen
Steffen Wilberg
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
Robert Kaiser
> 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
Mike Connor
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
Boris Zbarsky
> 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
Robert Kaiser
> 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
Tony Mechelynck
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
Boris Zbarsky
> 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
David E. Ross
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
Boris Zbarsky
> 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
Steffen Wilberg
Toolbar/Find in Page/Find Backend. I'd suggest to update the
reorganisation plan accordingly.
Steffen
Steffen Wilberg
Toolbar/Find in Page/Find Backend. I'd suggest to update the
reorganisation plan accordingly.
Steffen
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
>
> 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
Gervase Markham
> 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
Gervase Markham
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
Jonas Sicking
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
Boris Zbarsky
> 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
Robert Kaiser
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
Robert Kaiser
> 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
Boris Zbarsky
> 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
Reed Loden
Boris Zbarsky <bzba...@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 - <re...@reedloden.com>
Boris Zbarsky
> 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
Gervase Markham
> 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
John O'Duinn
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.
=====
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Robert Kaiser
> 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
Nelson Bolyard
> 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?
Gervase Markham
> 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
Jonas Sicking
> 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
Gervase Markham
> 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