we're having two bugs open right now  that may or may not merge, and
I wonder where the off-the-bug discussion should be. Trying .governance.
We may want to have more than one bug component per locale on the one
hand, and we have more and more stuff tracked in bugs that's not
strictly "Client Software", like website bugs etc.
I'm wondering if we should move "Mozilla Localizations" from being a
product to being a category, and to have a product per locale. That's
default to just a single "General" component, but would have additional
components for bigger and more diverse teams.
Not sure if we really want that, but I'd be interested to know what
other people think.
Downside seems to be mostly "enter_bug.cgi" and how to make it easy to
file new bugs there. Not sure what opportunities we have there.
 https://bugzilla.mozilla.org/show_bug.cgi?id=523126, new component
for l10n of www.mozilla.com,
https://bugzilla.mozilla.org/show_bug.cgi?id=520454, new component for
local community pieces
The options as I see them:
1) Move the "Mozilla Localizations" product from the "Client Software"
categorization to the "Other" categorization. Perhaps rename it
"Localization". Tell people to just file general community bugs in there
anyway, even if semantically it's a bit wrong.
2) Make Localization a categorization. There are two ways round we could
af / Afrikaans
ar / Arabic
as / Assamese
af / Afrikaans
as / Assamese
ar / Arabic
as / Assamese
To me, 2a) seems to make a bit more sense than 2b). And you could have a
General component which you could mildly abuse to file general community
issues you wanted to track. But perhaps others think differently.
> To me, 2a) seems to make a bit more sense than 2b). And you could
> have a General component which you could mildly abuse to file
> general community issues you wanted to track. But perhaps others
> think differently.
2b) seems overly complicated for filing bugs, and for building queries
that stay sane.
I like 2a) though, as it's easy to add new components to a product,
and it'd still be easy to see the high-level view for that
localization without having to constantly update queries.
As one who actually does Bugzilla administration (such as adding
components) on a very regular basis, I'm not sure I'd agree with "it's
easy", especially when you need to add a component to 40+ products, but
I do agree that 2a) is the best choice, and it's what I recommend.
I've been thinking about ways to possibly make it easier to do from an
admin perspective, and I have a couple of solutions in mind that will
hopefully help make this easy on the few of us who will have to
maintain this new layout.
Reed Loden - <re...@reedloden.com>
I'm personally not really fond of the idea to have one person tracking 3
or 4 bug components. I don't think that it's in our best interest to
have the complex setup be the default, and I'd just go with a single
"General" component for quite a few locales.
For those with different owners of Firefox and Thunderbird and possibly
Toolkit, having own bug components for those might make sense. If they
have further resources like a community site, great, another component.
I'm all ears for reed's technical alternatives, though, I might just
find them compelling.
Whether it's separated into components or not, I would think the query
people would want is to just query the product. Whether it's
Thunderbird or Firefox or General shouldn't especially matter.
That said, being able to drill down and prioritize a specific release/
project seems like an ability people shouldn't ignore lightly... (i.e.
Firefox release pending, check the Firefox bugs, not skim everything...)
For easy tracking, we could have default QA contact per locale *and* per
component plus a default CC per locale for all components. That is:
Product: pl / Polish
QA contact: pl.ge...@localization.bugs
default CC: p...@localization.bugs
default CC: gen...@localization.bugs
QA contact: pl.fi...@localization.bugs
default CC: p...@localization.bugs
default CC: fir...@localization.bugs
So you can either:
- track pl@ to get all notification for Polish, or
- pl.firefox@ for Polish Firefox in particular, or
- fir...@localization.bugs for all Firefox-related bugs across all
> For those with different owners of Firefox and Thunderbird and possibly
> Toolkit, having own bug components for those might make sense. If they
> have further resources like a community site, great, another component.
Wouldn't queries get more complicated or even indeterministic if locale
products have variable number of components? Say, if Firefox-related
bugs go into Polish > Firefox and Occitan > General, how do we make sure
we find them all without too much noise?
Script-automated bug filing for all or a subset of locales might be a
problem too. And we (l10n-drivers) do this a lot. We file 75 bugs for
search engines in Fennec, or 75 bugs for Firefox 3.6 'firstrun' page.
One bug for each locale. Right now we can use scripts to facilitate
this, but with the new solution, if some locales have the component we
need and others don't, there might be problems with automating this.
(It would be cool to specify 'General' as the fallback component in the
script, but AFAIK, something like this doesn't work in Bugzilla (at
least not now): <https://bugzilla.mozilla.org/enter_bug.cgi?product=pl
Due to the above concerns, I'd lean towards creating a couple of
pre-defined components for each locale that we know we'd have use for
(Firefox, Thunderbird, Fennec, Websites, General, ...others?) and then
allow each locale to add customized components depending on their needs.
In general, default CC's fail miserably because of behavior when bugs
change components. If you're certain that a bug will never leave a
domain, this is a different story.
> Due to the above concerns, I'd lean towards creating a couple of pre-defined
> components for each locale that we know we'd have use for (Firefox,
> Thunderbird, Fennec, Websites, General, ...others?) and then allow each
> locale to add customized components depending on their needs.
As mentioned earlier, in order to do anything like this, the admin
interface needs serious improvement. Mass adding components or making
similar mass changes is impossible today, instead it's a long and
repetitive process -- with room for making mistakes. I'd hope we can
work to improve Bugzilla before we roll out this reorganization.
one of the people who works on maintaining bugzilla's components
system (sadly, mostly marginalized by permissions)
(2009/10/23 23:16), Staś Małolepszy wrote:
>>>> I like 2a) though, as it's easy to add new components to a product,
>>> As one who actually does Bugzilla administration (such as adding
>>> components) on a very regular basis, I'm not sure I'd agree with "it's
>>> easy", especially when you need to add a component to 40+ products, but
>>> I do agree that 2a) is the best choice, and it's what I recommend.
>>> I've been thinking about ways to possibly make it easier to do from an
>>> admin perspective, and I have a couple of solutions in mind that will
>>> hopefully help make this easy on the few of us who will have to
>>> maintain this new layout.
>> I'm personally not really fond of the idea to have one person tracking 3
>> or 4 bug components. I don't think that it's in our best interest to
>> have the complex setup be the default, and I'd just go with a single
>> "General" component for quite a few locales.
> For easy tracking, we could have default QA contact per locale *and* per
> component plus a default CC per locale for all components. That is:
I'd rather like using only QA conact than this scheme.
* default CC will not maint when we change component (as well as product)
* per administrations, adding multiple options will cause failure easily.. :-p
* we can track multiple dummy accounts
(of cource, I'd want some better ui, instead of the current list with comma.
Such as listbox et al., which we currently have for CC box in each bug)
Of cource, there're some disadvantages but it's not hard than the first
in the above list.
* we should maintain tracking list when some new language are added..
# or, if bugzilla supports meta account, it will be nice. Like,
my account tracks gen...@localization.bugs and it tracks pl.general@,
Atsushi Shimono (aka. himorin @ irc) - shi...@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
-----END PGP SIGNATURE-----
We have a REST API now, too, or I guess will once the 3.4 stuff goes
live. That should give us pleasant new options...
We already have a webpage that fake that, utterly to totally
Might be good to adapt that to the REST API at some point, but it does
ease mass-filing bugs a good deal.
- a standard set of components per localization and product, i.e., a new
locale would be set up with
-- locale product
--- General (as fallback)
--- (Thunderbird as requested, etc)
There should be a QA contact for each as hinted at by stas, and an
overall alias watching each.
We'd want our initial localization team member to be on default-CC, if
possible, just because we had a few cases where they didn't actually
watch bugzilla aliases, and bugs went untracked.
Now that I got all those ponies lined up nicely in an indian summer
sunset, how do we make that feasible?
I could probably hook up some webpage like the bugfiling template, where
you'd fill out a form and it'd create a series of links to bugzilla
filling in the forms with the right values. Not sure if that works on
the admin interfaces. Or someone could hack something up server-side?
This is a huge maintenance burden on the people who maintain Bugzilla.
Plus the default cc list doesn't typically behave in any reasonable
> just because we had a few cases where they didn't actually watch
> bugzilla aliases, and bugs went untracked.
This is an education problem.
Nothing we're talking about comes cheap here. And it's not an education
problem, but a problem of scale. You make N teams do M tasks, and some
percentage of those go wrong or get dropped. Many of those we can find
because we can track it down, but not the watching part. Thus we should
remove the technical details from those that are new and overwhelmed and
put them onto people that are trained and skilled.
If editing a default-CC is wrong, can we edit other users pref to just
make them watch the general alias instead?
Lastly, if this is a problem we can make easier with tools, we should,
if this is a problem that can only solved with people, we should add
people. If this is just a problem for the transition of one scheme to
the other, we should just add people for that task, and rip their privs
This is technically possible, i've done it at other installs using
impersonation, but that credential is um.. well...
Let's say that to do this right, we need delegation instead of
impersonation. If delegation existed and all of your localizers were
configured to delegate user pref changes to a localization management
group, then it'd be easy to do this in a relatively proper manner.
Delegation sadly is just a wish (impersonation is basically something
that large installs will almost never use except to record undoing
some mistake made by an admin [e.g. if the admin -- me-- accidentally
deleted people's voting records and the admin -- me-- wants to show
that he's putting them back, the admin -- me-- can use impersonation
to restore a voting record], but because impersonation isn't limited
to anything, it's a "you can impersonate anyone", it's a god privilege
and is almost never enabled or used).
> Lastly, if this is a problem we can make easier with tools, we should,
if you have the resources to get someone to implement delegation,
that'd solve this problem from a management task. Someone implements
delegation or even delegation just for pref editing. We create a
locale management group. You submit a list of all the localization
accounts. We mass add delegation of pref editing to the locale
management group. Someone from the locale management group then gets
to deal with adding watching per user according to their team.
> this is a problem that can only solved with people, we should add people. If
> this is just a problem for the transition of one scheme to the other, we
> should just add people for that task, and rip their privs afterwards again.
Someone could give out impersonation today, or we could cheat and
write SQL to forcefully add the watch bits based on a table you
provide. I suppose raw SQL is probably preferable (from a security
standpoint) over giving out impersonation. From a purity perspective,
I prefer how impersonation works, since its actions are logged and
emails are sent to the victims indicating who is using it and the
reason they gave.
I think we trust Axel enough to give him Bugzilla admin privs so that if
this is what he wants, he can set it up and maintain it without
bothering you, me, reed or justdave.
You think Axel may not know all he needs to in order to do this? That's
OK - it's just an education problem.
I can give you an admin account on one of the Bugzilla test installs on
landfill.bugzilla.org if you want to test some automation code for
creating all this.
Sadly, reading the code, I don't think it's going to be possible to
prefill the product or component creation forms using a URL without the
support of a Greasemonkey script or Jetpack.
Being able to test the impact of such a move across the UI would be
required, yes. I was hoping to get some help on landfill with that, too.
The latest UI I was wondering about was the full query dialog. That
might go somewhat unwieldy, too? Might be good to check in some quick
search tricks, too, in particular if it comes down to Product Firefox vs
Let me know if you need anything else.
> The latest UI I was wondering about was the full query dialog. That
> might go somewhat unwieldy, too?
I wouldn't worry about that.
> Might be good to check in some quick
> search tricks, too, in particular if it comes down to Product Firefox vs
> Component Firefox.
If you have patches... :-)
> The latest UI I was wondering about was the full query dialog. That
> might go somewhat unwieldy, too? Might be good to check in some quick
> search tricks, too, in particular if it comes down to Product Firefox vs
> Component Firefox.
It shouldn't be unwieldy... You should be able to select "Localization"
as the classification and then pick Firefox from the components list.
That will give you all the Firefox components within the Localization
classification. I believe that's what you're looking for, correct?
I was actually more concerned about people searching for regular Firefox
bugs than l10n bugs. Not sure how often folks actually start with the
category and then select the product. If they do, we're cool.
Many bugs demonstrate upstream escalation life cycle:
1. Users submit bugs to national Mozilla community Bugzilla instances.
There are quite a number of them, and localized UI sometimes makes
them preferred entry points for national communities.
2. Bug gets confirmed, and filed upstream into b.m.o. by local team
member, with better English and bug reporting skills.
3. Initial reporter tries to track such inter-Bugzilla dependency.
Of course this is not limited to l10n bugs, it just adds one level of
indirection: reporter, _translator_, assignee, QA...
As Bugzilla is (slowly) moving to better inter-instance cooperation
capabilities, some day we may need to map local class-product-
component sets to these of b.m.o, for inter-Bugzilla dependency
There is a "related bugs" feature in Bugzilla 3.4 (and b.m.o. is
upgrading very soon to 3.4), which takes arbitrary URLs. It is designed
exactly for this sort of thing. It's a looser coupling than a direct
mapping, but I think that's a good thing.
I'm still not quite understanding your concern.
Can you spell it out in a bug-report sort of way by saying "If a user
comes and clicks X, types Y and hits submit, they will get the wrong set
of bugs, because they expected P to be true but in fact this change will
mean that P is not true"?
If a user comes in and queries for bugs in the component Firefox,
they'll not get the bugs in the product Firefox.
Looking at the current stats in query.cgi, we have 641 components and 47
products, moving 80 from one to the other shouldn't make things that
Yes, we may have reached a local minimum for taxonomy usability. :-/
Oh, I see :-) The problem of components and products having the same name.
I think this is just another indication that the complicated query form
is not to be used by people who wouldn't get that distinction, and if
the simple query form isn't good enough, we need to improve it.
One thing I found is that watcher of watchers don't work. So the
per-locale-cross-product and the cross-locale-per-product watchers
aren't working. People interested in say, all German bugs or all web
bugs would have to add each QA contact to their own watch list.
Regarding default-cc, is there a rationale why those don't get added
along with default assignee and QA contact when moving a bug from one
component to the other?
Manipulating watch lists only works via impersonation, it seems. There
are bugs on file to make that less restrictive, not sure which one would
win. I guess for my use case, it would even be enough to see the list of
watchers and watched accounts somewhere in editusers.cgi. I could nag
One thing that I found and that's not really pretty is when you move a
bug from one product to the other, we'd add all localizations there. Not
sure if that's a blocker, though.
Other than that, I think that going with a Category Localization and
products per locale, component per app/web/etc sounds like a good idea.
If reed doesn't have better technical tricks, we'd probably write an
extension to help with the admin part of it. jetpack doesn't seem
powerful enough just yet.
On 20.10.09 14:50, Axel Hecht wrote:
> we're having two bugs open right now  that may or may not merge, and
> I wonder where the off-the-bug discussion should be. Trying .governance.
> We may want to have more than one bug component per locale on the one
> hand, and we have more and more stuff tracked in bugs that's not
> strictly "Client Software", like website bugs etc.
> I'm wondering if we should move "Mozilla Localizations" from being a
> product to being a category, and to have a product per locale. That's
> default to just a single "General" component, but would have additional
> components for bigger and more diverse teams.
> Not sure if we really want that, but I'd be interested to know what
> other people think.
> Downside seems to be mostly "enter_bug.cgi" and how to make it easy to
> file new bugs there. Not sure what opportunities we have there.
>  https://bugzilla.mozilla.org/show_bug.cgi?id=523126, new component
> for l10n of www.mozilla.com,
> https://bugzilla.mozilla.org/show_bug.cgi?id=520454, new component for
> local community pieces
Yes, this is true. Sorry - there's no good fix for that. Unless we
decide to make all the German-related l10n components have the same QA
> Regarding default-cc, is there a rationale why those don't get added
> along with default assignee and QA contact when moving a bug from one
> component to the other?
You'd need to ask the Bugzilla developers that.
> Manipulating watch lists only works via impersonation, it seems.
You mean that it's only possible to change what someone is watching if
you are that person? That sounds like a feature, not a bug...
> One thing that I found and that's not really pretty is when you move a
> bug from one product to the other, we'd add all localizations there. Not
> sure if that's a blocker, though.
Sorry, I don't understand what you mean by this.
There is https://bugzilla.mozilla.org/show_bug.cgi?id=121386 claiming
the opposite, at least to some extent.
>> One thing that I found and that's not really pretty is when you move a
>> bug from one product to the other, we'd add all localizations there. Not
>> sure if that's a blocker, though.
> Sorry, I don't understand what you mean by this.
Head over to any bug on bmo, and then use the drop down for switching it
to a different product. That drop-down is not restricted by
classification, so that drop-down would increase by some 80-100 entries.
Oh, dear :-( I had totally not thought of that.
Looks like we are back to suggestion 2b), then? That only has a small
number of additional products (perhaps "Firefox Localizations",
"Thunderbird Localizations" and "Other Localizations"?)
I've set this up, for example there's
I'll ask for wider feedback a bit.
On my tests on
a bug from one component to the other does add the default CC.
So not sure what problem you're raising here.
I'd say pretty high, unless you think that people move bugs merely for
the fun of it.
In this scenario, I don't see bugs moving in and out of various l10n and
non-l10n components, picking up random CCs all over the place. And even
so, un-CC-ing oneself is easy enough to do.
It'll depend on how you structure your components. But if you have a
'web team', a 'firefox' team and a 'thunderbird' team, and the bug is
filed in 'firefox' and is moved by someone to 'thunderbird' and later
correctly moved to 'web', then i'd imagine that the firefox and
thunderbird people will not have cared. This is assuming slightly
confused reporter, a slightly bad fix, and a set of teams which really
do work independently (i.e. fft!=tbt!=webt).
You're free to do whatever you like. I'm just explaining the downside
in advance so I can say "i told you so" later.
There's also the bigger problem that maintaining the CC list (at least
historically) requires an admin (or similar). i.e. you're creating
useless bits, not teaching people to use bugzilla properly, and
bogging someone down in administration.
So are you suggesting that if someone was added as a "default CC",
Bugzilla should un-CC them when the bug moves out of that component?
It doesn't do that for assignees and QA contacts, unless you ask it to
You are also positing what I would suggest is a pretty unlikely
scenario. There aren't many bugs which bounce around this way. And if a
bug is filed in a "to be triaged" component and then moved, I suggest
that person A1 who has default-CCed themselves to all "to be triaged"
bugs is getting exactly what they wanted.
I'm suggesting that it's impossible to understand what it means, and
as such is fundamentally broken.
> It doesn't do that for assignees and QA contacts, unless you ask it to
doesn't do what?
when we change component in the field picker today, it automatically
selects 'reset'. which means whomever was the old assi or the old qa
will stop getting mail (unless they have some other role which gives
them a chance for mail..).
> You are also positing what I would suggest is a pretty unlikely
> scenario. There aren't many bugs which bounce around this way. And if a
> bug is filed in a "to be triaged" component and then moved, I suggest
> that person A1 who has default-CCed themselves to all "to be triaged"
> bugs is getting exactly what they wanted.
I question this. I suspect that people will not understand that this
is what they're getting.
I claim that people signing up will expect "i'm doing this because i
want a cc on bugs that need to be triaged" but "once the bug is
triaged, i don't care anymore" and they will *not* understand that
they will get bugmail for life (of that bug).
Roughly. I claim that there is no use case for the default CC field
(it's just a horrible maintenance burden). Whereas there is a use for
explaining to people how to watch components. If someone cares about 3
components, teach them how to watch those components.
Arguably, there's a use case for product watching, which is basically
"if i sign up to watch all available components of a product today,
and am on vacation for 3 days during which someone adds a new
component to the product i was watching, then i will miss any bugs
that got into those new components because i couldn't watch the
product". However, I claim that this should be covered by a rule that
'if a user is watching all components in a product and a new component
is added, then we magically add them to the watch list for the new
component' when they get back from vacation, if they change their
mind, they can remove themselves from ones they don't care about,
after which if a new component is added, they won't get a watcher role
for that either because they're no longer watching all in a product.
Teach people to fish: teach them how to watch accounts. (And if you
have the resources, provide proper automatic watchable accounts
instead of relying on our manual watchable account creation).
Yes, indeed. I'm not arguing that 2b) is great. It's just that, if we
exclude "hacking Bugzilla" as part of the solution (and I think that's
wise, if we want to do something quickly, because b.m.o. is conservative
about change) then 2a) leads to an unmanageable product name explosion.
Another option would be a second Bugzilla installation.
Semantically, neither "product=Polish" or "component=Polish" make much
> Also (and IMO), pointing people to right enter_bug.cgi page would be
> easier with 2a). I find it more natural to say "Stas, go to
> enter_bug.cgi?product=Polish and choose the right component for your
> problem" than to say "Stas, go to
> is-a-root-cause-of and choose Polish as the
> component". It might be my personal preference, though.
enter_bug.cgi?product=Firefox%20Localizations&component=Polish ? :-)
> If the dropdown issue is a big one, maybe we could work around it by
> prefixing the locale product names with a certain string? This would at
> least group them all in one place. For example, "Localization: de" or
> even ".de" (with a point or some other punctuation decorator). Hacky as
> this might seem, it could actually be pretty conveninet for
> quicksearching (":~fi" would only return bugs filed for Finnish locale,
> contrary to ":fi", which will give you "product:Firefox" as well).
I think if we went for product names, we'd definitely need a prefix.
"product=Polish" is confusing. product="Localization: Polish" is a bit
> I would also like to suggest that we only use locale code in the
> product/component name.
If it's the component, I could go for that. (Although it would either
mean we had to rename a bunch of existing components - again - or mean
people had to select two entries in the list to do a wide search.) If
it's the product, I can't imagine making our Product list 75 products
bigger, all of which have names like "fa" and "sk".
I see your point, but somewhere inside me I'm not OK with going with a
suboptimal solution for a change that's that big just because of a
shortcoming of the current version of the tool (bugzilla). My preferred
way would be to go with 2a) and file a bug to make product dropdown more
manageable in a future version of bugzilla (with an <optgroup
label="Classification label"/> for example?). In fact, I just filed it:
> Another option would be a second Bugzilla installation.
That would make moving bugs to other classifications hard, of not
impossible (?). Sometimes localizers file bugs in their locale's
component which turn out to be bugs in the product's code (Firefox,
toolkit etc.), and are consequently moved to other products. i think
that's something we wouldn't like to loose.
For example, I could file a bug in the Polish component about some
string being too long in the Polish version, but it might turn out that
it's in fact a bug affecting all locales because of a sizing issue in
the source code. As a localizer, I'm filing this in my component because
I'm not aware of the situation in other locales and/or because filing a
bug in Firefox > Something is too scary for me :) L10n-drivers still
have a possibility to triage this bug accordingly and move it to the
right product if necessary.
> Semantically, neither "product=Polish" or "component=Polish" make much
> sense... :-(
True, but I don't think we have any other options.
>> Also (and IMO), pointing people to right enter_bug.cgi page would be
>> easier with 2a). I find it more natural to say "Stas, go to
>> enter_bug.cgi?product=Polish and choose the right component for your
>> problem" than to say "Stas, go to
>> is-a-root-cause-of and choose Polish as the
>> component". It might be my personal preference, though.
> You mean:
> enter_bug.cgi?product=Firefox%20Localizations&component=Polish ? :-)
Yes. I think that enter_bug.cgi?product=Polish makes sort of a nice
homepage of the Polish locale on bugzilla where you can easily point
>> If the dropdown issue is a big one, maybe we could work around it by
>> prefixing the locale product names with a certain string? This would at
>> least group them all in one place. For example, "Localization: de" or
>> even ".de" (with a point or some other punctuation decorator). Hacky as
>> this might seem, it could actually be pretty conveninet for
>> quicksearching (":~fi" would only return bugs filed for Finnish locale,
>> contrary to ":fi", which will give you "product:Firefox" as well).
> I think if we went for product names, we'd definitely need a prefix.
> "product=Polish" is confusing. product="Localization: Polish" is a bit
> less so.
Agree, although I'd probably vote for product="Localization: pl" instead
of product="Localization: Polish".
>> I would also like to suggest that we only use locale code in the
>> product/component name.
> If it's the component, I could go for that. (Although it would either
> mean we had to rename a bunch of existing components - again - or mean
> people had to select two entries in the list to do a wide search.) If
> it's the product, I can't imagine making our Product list 75 products
> bigger, all of which have names like "fa" and "sk".
That's why I suggested using a prefix. And I think naming a product
"Localization: fa" is fine as long as the description on enter_bug.cgi
says "Persian localization". I assume that people using the dropdown
(when changing products in existing bugs) are familiar enough with
Bugzilla, Mozilla and l10n to know what "fa" means. On the other hand,
the product description on enter_bug.cgi would help other people know
where to file bugs related to the Persian localization.
So. There are two sides to this coin. I've been on both sides.
If you file a bug because you see a problem in the Polish
localization, then someone else might file the same bug because they
see the same problem in the same Polish localization.
Now if your bug is moved from Polish to Firefox, then when that second
person goes to file their bug, they might not search Firefox and might
therefore file a duplicate.
In this case, i'd argue that it's often better to leave turds or
pointer bugs around essentially as bookmarks.
Besides, your original bug probably has investigation which isn't
really needed for the bug that goes to the firefox side (heck, it
might start out written in Polish).
Essentially, bug-dependencies are IMO a better way of handling this
sort of problem. Bugzilla now has a see-also field which allows the
beginnings of bug tracking across bug databases. Eventually Gerv or
someone will improve it so it at least shows state and stuff where
Note: I'm not saying we definitely should use a second bugzilla or
that you should always avoid moving bugs, however I'm definitely
leaning toward always leaving a bug in e.g. Firefox when we need a bug
in Core. Because we're going to get more bug filers filing the bug in
Firefox, and we don't really need the original e.g. Firefox end users
commenting in the bugs once we've found the Core problem.
This is of course part of some larger conversation that I haven't had
time to try to direct, but....
If the audience for this activity is l10n-drivers, then I would
suggest that you write a jetpack to make the re-filing of such bugs
simple and pleasant. That seems to be our standard modus operandi for
overcoming interface limitations in bugzilla these days, and it works
pretty well. It could leave a "see also" entry in the source bug, put
one in the target bug, put a nice message in the source bug about
what's happened (possibly selecting the languages for that explanation
based on the localization-product in question!), and generally give
hugs and foot rubs all around.
It would also have the benefit that the bug filed against Firefox
would start with a clear description of the Firefox issue, rather than
a description of a specific string issue (possibly not in English) and
then a bunch of comments leading up to the discovery that it's a core
bug. Much better than resorting to "FIREFOX ISSUE STARTS AT COMMENT
12" in the status whiteboard!
It's pretty nice once you get out of the stockholm-syndrome sort of
relationship with bugzilla's current behaviours, and are able to again
start treating it as something we can mutate quickly to suit our
unique needs. I recommend it!
On 21/10/09 11:04, Gervase Markham wrote:
> The options as I see them:
> 1) Move the "Mozilla Localizations" product from the "Client Software"
> categorization to the "Other" categorization. Perhaps rename it
> "Localization". Tell people to just file general community bugs in there
> anyway, even if semantically it's a bit wrong.
Here's another option. It's basically option 1, but the components of
the Localization product are as follows:
"af: Community" (or General or whatever)
This seems to solve most of the problems:
- One Bugzilla, not two :-)
- Doesn't cause a massive increase in the number of Products
- Allows varying number of components/divisions per locale, based on
- Makes it easy to have a search involving all components for a
particular locale (use e.g. /^af:/)
- Default QA contacts could be per-locale or per-component, to be
One disadvantage might be that it's a long component list. But that's
better than a long product list.
I still have to think about this a tad, or rather, set up the l10ntest
bugzilla db with a more appropriate scenario so that one can see that in
One thing that I don't like is not having human readable language names
in the components. We should have the locale code in there to do tool
tricks with it, but I don't think that users filing bugs need to
understand the concept of locale codes.
Good point here. Many locale codes are not as straight-forward or
recognizable as some of our most prominent locales. Someone might
wonder what the locale "cy", "el", "eu", or "hr" means. (BTW: Welsh,
Greek, Basque, and Croatian.)
Also, not that it is a big deal, but in this scenario, adding new
locales or products would mean making several changes to the Bugzilla
component list rather than one. But, that doesn't seem to be a huge deal.
When can we summarize the options here and settle this discussion?
Gerv, would you be willing to take the lead on summarizing the option,
feedback and proposed way to resolve? Perhaps it's just my opinion, but
I feel like we need to wrap up this conversation now and come to a decision.
Good point here. Many locale codes are not as straight-forward or
I think you are right, and I'm on the hook for driving consensus. This
new proposal was the result of an attempt to do just such a settling. If
no-one objects, it'll be what we go with.
There are two mutually-exclusive ways we could go here:
- Use locale codes only. Pro: names of components can be easily
programmatically determined. Con: less clear.
- Use locale codes + English names, or just English names. Pro: more
clear. Con: can't easily programmatically determine name of component.
I think Stas was arguing for the first, and you are arguing for the
second. Have a cage fight, and let me know who wins :-)
I strongly suspect we can overcome the con here, since it's just a
look-up table (or scanning of a list for something that matches the
locale code in a known position).
Sure :-) I'm arguing for Stas here. He wrote in another message in this
> I would also like to suggest that we only use locale code in the
> product/component name. This makes hacking up tools and giving out
> enter_bug.cgi URLs really easy (I don't have to even think about what
> the English name of the locale is).
We have code that deals with the current component names just fine, all
I do is split on " / " and I have the locale code.
Anything as easy as that will work.
I'm not so fond of the single list of l10n components, mostly because
you can't do funny tricks as easily (AFAICT) using the /count bzapi for
It's not really the day to press on the decision here without using the
opportunity to gather data, both from having the different schemes up in
the amount that they'd be needed, nor having asked the l10n community as
Feel free to publicise this discussion anywhere you think appropriate,
so that people can come over and add their viewpoint. But we don't want
to be here for another six weeks.
Quick status update:
I'm working on an extension to do the tedious work here, for an
incarnation of all three schemes.
Sadly, the bugzilla admin pages are hacked to be non-scriptable (read
tokens), so I really have to load forms and fill them out. Of course,
html forms dom doesn't work the way it does in html once you access an
iframe from chrome. And of course I think I should use a wizard to go
through the steps, and that just breaks if I try to use jquery,
https://bugzilla.mozilla.org/show_bug.cgi?id=541916. So I'm stuck using
iframes and event handlers and figure out all the fun about closures
myself. Oh, and search for crashreports on 3.6 mentioning "venkman" in
the comments, too.
All that to say, it's a nasty bugger.
But are you asking the l10n community to come and comment on the
proposals, which is something you said was important? :-)
Can we decide on which scheme we are using at the same time?
Getting it all set up is the responsibility of the Bugzilla admins. They
may well appreciate your help and your tool, but we shouldn't let your
tool-writing block us making a decision on what we are actually doing.
Who else needs to comment on this before we can pick my new plan? Name
A name to name would be me. And I want to see all three schemes in
action with the 80+ components we have before I actually nail it down.
here's the proposal coming out of the thread in .governance. Quick recap
for .l10n: We'd like to re-arrange how we do bugzilla components for
l10n, to achieve a few things:
- get a better at exposing work items for people to pick up
- get a better grip on the web bugs, and not spam the websites folks
with all l10n bugs there
- better track what bugs are open, both within a particular localization
and across localizations.
There has been a good deal of back and forth, but l10n-drivers and Gerv
came up with the following that we'd like to do:
- create a new categorization (like "Client Software") for l10n bugs,
called "Mozilla in Your Language".
- within that classification, have a "product" (bugzilla term) per
l10n: Afrikaans (af)
l10n: Arabic (ar)
- within each product, have a bunch of components.
Those are created as needed, i.e., locales without Fennec don't have
that component set up.
Each of those components has a QA contact like
"firef...@localization.bugs" and a default-CC of
"a...@localization.bugs, firef...@localization.bugs", default assignee
The existing locale-bugs will be migrated into the new components (with
some community help), and the old components will be removed. The
components for Registration and Infrastructure will stay where they are.
Ricardo, what to do with MT?
All components will have their QA contacts and default assignee per
scheme, and we'll need to get all localizers to move over to watch the
new aliases (we can probably rename the current ones to ease that a
bit). This is a change for some locales, but it's going to make it
easier for new contributors to just go in and watch the bugzilla
component they're interested in.It'll also be easier for us to CC
aliases if we're interested in feedback from particular locales on
non-l10n bugs etc.
The new bug templates will be adjusted to expose "Mozilla in Your
Language" as fits.
The whole thing should make bugzilla a more powerful tool for all of us,
and make it easier to join existing localization efforts, too.
Known drawback: When moving a bug from one component to the other, all
products independent of classification are shown. We'll make that list
longer, sorry. The good news is, all l10n products are prefixed with
"l10n:" so it's easy to skip, and, only experienced bugzilla users with
added bugzilla priviledges can even do that, so we're not hitting
unexperienced bugzilla users. Nor is it an action that happens *that*
We hope you like it, and if there are no blockers discovered, we'll move
forward with this scheme soon.
The proposal seems fairly reasonable.
I wonder if we can improve Bugzilla so that it only shows people
products they've used. We already have an interstitial page for
components, so in theory it should be possible to do something more
intelligent. I'll try to write a proposal at some point.
What about Mozilla Communities? Will be moved to new location too?
Product: Mozilla Communities
Component: cs or es-MX
See Bug 520454.
I'm not sure yet, I'm open for opinions. It's not something we need to
decide ad-hoc, either, IMHO. There don't seem to be any bugs in the
es-MX component to begin with, so the practical impact of that being
"available" across locales seems to be low.
Might be worth to get some feedback from you guys on how that component
is doing for cs. Found 77 bugs in there, but can't read a single one of
Yes, it's in czech because it's better for some part of our community.
This component is used for tracking bugs which are related to our
community and our websites (for example: http://www.mozilla.cz/).
I agree that this isn't something whan we need decide at this moment.
Just for info. We don't have problem to stay in this component.
Sorry, I've been somewhat offline these days. I browsed your post and
inmediately thought of MT, yes.
Regarding your question, most modern bugs filed on MT were created by
myself to track changes in the application, so it seems that not a lot
of people will miss if MT component disappears from bmo. In fact, I'll
be releasing a new version RSN and I was too lazy to file bugs for
every change in this new version.
I've been reviewing my permissions on Sourceforge.net where the
project has its code (https://sourceforge.net/projects/moztrans/) but
I can't assign myself filed bugs in it (why I don't have full
permissions there is a long story).
So I could create a new project on either Sourceforge.net or other
place and migrate both the code and the bug system there, starting
with the new version of MT. Since that moment, MT bugs should be filed
in the new project site.
What would happen to MT old bugs? Will they still exist and be
searchable? Or should we just forget them?
For changing bugs, I think moving a bug to one side of the "l10n" to
another (e.g. Thunderbird -> Core) would be more difficult, because its
not just one or two simple scrolls with the wheel. However, that's a
rare operation, so maybe it isn't too bad.
The search page is also another potential problem, but I guess at least
we have the classification there to filter out the L10n products should
we not want to scroll through them.
Just some thoughts.
Yeah, we've discussed this in this thread on .governance before. The
outcome was that this is OK, as it's both rare, and the current list is
tough already. Also, it's hitting experienced bugzilla users only.
> The search page is also another potential problem, but I guess at least
> we have the classification there to filter out the L10n products should
> we not want to scroll through them.
> Just some thoughts.
To quote shaver from elsewhere in this thread,
> Yes, we may have reached a local minimum for taxonomy usability. :-/