bugzilla.mozilla.org improvements

12 views
Skip to first unread message

Gervase Markham

unread,
Jun 12, 2009, 7:35:05 AM6/12/09
to
Over the next few months, I will be working on improving
bugzilla.mozilla.org to better meet the needs of the Mozilla development
community.[0] I am therefore gathering 'requirements' - that is to say,
asking people's opinion about which possible improvements would be most
useful. This newsgroup post and an associated blogpost pointing here are
a start; please let me know if there are other forums I could usefully
ask in.

(I apologise if the reasonably wide crossposting irritates anyone. It
seems that mozilla.announce has morphed into something which
non-community-members subscribe to for notification about updates to
Firefox and Thunderbird, so I suspect it's no longer appropriate for
this sort of message. Perhaps we need a mozilla.dev.announce.)

Please say what the change you are requesting is, and why making it
would improve your life. References to previous discussions and bug
numbers would help.

Feel free to suggest configuration changes as well as code changes, of
sizes both big and small. I anticipate working on maybe 1 or 2 larger
things, but I hope to also be able to fix some small-but-annoying things
along the way. I can't promise that any particular change will be worked
on, even if supported very vocally. There are a number of factors which
will affect the decision, including our desire to help the Bugzilla
development community achieve its goals - both technical and social.

I can't promise a timeframe by which the changes will be available. My
aim is, for non-b.m.o.-specific changes, to get them into the Bugzilla
trunk and have them flow down to b.m.o. from there. And so it is
dependent on Bugzilla release schedules and b.m.o. upgrades, which are
themselves dependent on our release cycles and on IT time.

Gerv

[0] See my full SOW here:
http://weblogs.mozillazine.org/gerv/archives/2009/06/new_sow.html

Axel Hecht

unread,
Jun 12, 2009, 7:49:07 AM6/12/09
to
My pet would be a truly-JSON API to get data out of bugzilla. Our use
case is the l10n dashboard, which we'd like to have bugilla integrated
with. I'll probably need to get to my drawing board to give some
concrete queries we'd want. Here having aggregated data is a big win,
too. 75 queries to bugzilla suck, where we'd really want something like
"number of open bugs per component in l10n" or "number of open blockers
of bugs with an alias matching 'fx35-l10n-.*'"

A smaller thing would be to support filling in the alias via the URL. I
have forms that generate those urls from data, so having the alias makes
sense (more than in the case of static links). This is bug 310532. When
filing the flock of bugs for new locales, getting the alias right is
manual work each time.

I guess that finding out a better way to have "fixed here, but needs
fixing somewhere else" would be cool, and support for that in queries.

Shorter query urls by default, maybe.

Better caching? Not sure, but I think we reload a lot these days.

I guess that's my ad-hoc list.

Axel

Dave Townsend

unread,
Jun 12, 2009, 8:10:15 AM6/12/09
to
On 12/06/2009 12:49, Axel Hecht wrote:
> My pet would be a truly-JSON API to get data out of bugzilla. Our use
> case is the l10n dashboard, which we'd like to have bugilla integrated
> with. I'll probably need to get to my drawing board to give some
> concrete queries we'd want. Here having aggregated data is a big win,
> too. 75 queries to bugzilla suck, where we'd really want something like
> "number of open bugs per component in l10n" or "number of open blockers
> of bugs with an alias matching 'fx35-l10n-.*'"

Along these lines, being able to pull the chart data out through JSON or
even anything that didn't require you to be logged in would make it
easier to do nicer graphs than bugzilla can handle.

Oh and nicer graphs would be good :)

Nikolay Shopik

unread,
Jun 12, 2009, 8:35:13 AM6/12/09
to
On 12.06.2009 15:35, Gervase Markham wrote:
> Please say what the change you are requesting is, and why making it
> would improve your life. References to previous discussions and bug
> numbers would help.
Bug 209181 will save lots time when processing lot bugs and you need to
know if reporter mail not bounced.

Gervase Markham

unread,
Jun 12, 2009, 9:55:38 AM6/12/09
to
On 12/06/09 12:49, Axel Hecht wrote:
> My pet would be a truly-JSON API to get data out of bugzilla. Our use
> case is the l10n dashboard, which we'd like to have bugilla integrated
> with.

Is it good enough to have the JSON API have the same capabilities as the
current query page, or do you need more?

> too. 75 queries to bugzilla suck, where we'd really want something like
> "number of open bugs per component in l10n" or "number of open blockers
> of bugs with an alias matching 'fx35-l10n-.*'"

One additional thing I'll guess you need is an option to return a count
rather than the bug data?

> A smaller thing would be to support filling in the alias via the URL.

I have no idea why this doesn't work at the moment. I can see why people
object to it being part of the bookmarkable template (it makes it much
more likely for submitting the template to throw an error) but I have no
idea why &alias=foo on the URL doesn't work. This just seems like a bug.

Gerv

Gervase Markham

unread,
Jun 12, 2009, 9:56:33 AM6/12/09
to
On 12/06/09 13:10, Dave Townsend wrote:
> Along these lines, being able to pull the chart data out through JSON or
> even anything that didn't require you to be logged in would make it
> easier to do nicer graphs than bugzilla can handle.

I think we required a login to view charts because otherwise it makes it
very easy to DOS Bugzilla. But we could re-examine that decision.

> Oh and nicer graphs would be good :)

:-)

Gerv

Andrew Sutherland

unread,
Jun 12, 2009, 10:22:43 AM6/12/09
to
On 06/12/2009 04:35 AM, Gervase Markham wrote:
> I can't promise a timeframe by which the changes will be available. My
> aim is, for non-b.m.o.-specific changes, to get them into the Bugzilla
> trunk and have them flow down to b.m.o. from there. And so it is
> dependent on Bugzilla release schedules and b.m.o. upgrades, which are
> themselves dependent on our release cycles and on IT time.

Given that you will be doing things the right way with all the latency
that implies, I think the best thing is to focus on making bugzilla
something that people can easily experiment with and hack on.

As Axel suggests, I think this translates into making as much as
possible have a JSON API, and then having some documentation and
examples. Right now you can do/get a lot using XML (and some via JS),
but because of cross-site restrictions[1], this leaves you needing to
either operate with chrome privileges or have your server do a mod_proxy
trick.

While I think there are serious workflow issues in bugzilla that need to
be dealt with, I think it's a better idea to be able to prototype
workflow solutions and use them than to have to develop them in
comparative isolation and have to go through a release cycle to be able
to see the results. Things that require new fields or other constructs
in bugzilla could be 'worked around' in prototypes by using a CouchDB
instance to store the meta-data, for example.

From what I can see, bugzilla is already pretty close to having a
usable remote API, so it seems like a beneficial initial strategy...

Andrew

1: Grepping bugzilla trunk, I saw no mention of the
Access-Control-Allow-Origin header that would allow cross-site XHR in FF
3.5, and a quick check against bmo using "wget --server-response" did
not show the header being introduced by the server either. Just having
the server enable the header is probably a very wrong thing because of
the potential horrible cross-site hacks.

John J. Barton

unread,
Jun 12, 2009, 11:38:25 AM6/12/09
to
Gervase Markham wrote:
> Over the next few months, I will be working on improving
> bugzilla.mozilla.org to better meet the needs of the Mozilla development
> community.[0] I am therefore gathering 'requirements' - that is to say,
...

> Please say what the change you are requesting is, and why making it
> would improve your life. References to previous discussions and bug
> numbers would help.

1. Support for user-id auto-complete or lookup in the CC field. It
seems that lots of folks use a different email address in bugzilla than
they do in email or newsgroups. If you try to CC the other address,
bugzilla rejects the post because the email address is unknown to it.

2. Support for figuring out which build a FIXED bug shows up in.
Notifications when the first such build is available. Firebug gets a bug
report that we track down to mozilla, then we add a bugzilla report.
Then we watch dozens of emails over months as the fix moves forward.
Then the bug is marked FIXED and we are left in limbo. We can't tell our
users to try it and yet we won't get another prompt about the problem.
Our users think we left it on the floor.

jjb


Mike Shaver

unread,
Jun 12, 2009, 11:52:33 AM6/12/09
to John J. Barton, dev-pl...@lists.mozilla.org
On Fri, Jun 12, 2009 at 11:38 AM, John J.
Barton<johnj...@johnjbarton.com> wrote:
> 2. Support for figuring out which build a FIXED bug shows up in.
> Notifications when the first such build is available. Firebug gets a bug
> report that we track down to mozilla, then we add a bugzilla report. Then we
> watch dozens of emails over months as the fix moves forward. Then the bug is
> marked FIXED and we are left in limbo. We can't tell our users to try it and
> yet we won't get another prompt about the problem. Our users think we left
> it on the floor.

FWIW, "the first such build" for FIXED bugs is always going to be "the
next nightly from trunk", where you should presume those builds are
taken from around 3AM Pacific.

Mike

John J. Barton

unread,
Jun 12, 2009, 12:13:53 PM6/12/09
to
Gervase Markham wrote:
> Over the next few months, I will be working on improving
> bugzilla.mozilla.org to better meet the needs of the Mozilla development
> community.[0] I am therefore gathering 'requirements' - that is to say,
...

> Please say what the change you are requesting is, and why making it
> would improve your life. References to previous discussions and bug
> numbers would help.

Remove all of the relative version number aspects of bugzilla, eg
'trunk'. Since some bugs live longer than the binding of 'trunk' to
1.9.1, the word is ambiguous and you always have to double check it.

jjb

John J. Barton

unread,
Jun 12, 2009, 12:23:26 PM6/12/09
to

Ok then for Grev's list:

A better UI for nightly builds that includes:
1) a naming convention in user terms ("Firefox 3.6 June 6 2009")
2) a date-last navigation tree (mozilla/firefox/3.6/date, not
firefox/date-mozilla),
3) information about the unit-test status of the build,
4) a way to get notified about the next nightly build after a FIXED
bug that will be usable. (Maybe it would fun to do this via social
mechanisms, have nightly build instrumented to push "I came up!", "I ran
and exited cleanly!", "I crashed badly :-(" to the nightly-build server.

jjb

Dave Townsend

unread,
Jun 12, 2009, 12:12:14 PM6/12/09
to

I'd just remove the version field, it mostly isn't used for anything useful.

Daniel Veditz

unread,
Jun 12, 2009, 12:13:20 PM6/12/09
to
Gervase Markham wrote:
> I think we required a login to view charts because otherwise it makes it
> very easy to DOS Bugzilla. But we could re-examine that decision.

I assume you're talking about the "new" charts? There's also privacy
concerns because the charts could be answering questions about bugs in
private groups.

Benjamin Smedberg

unread,
Jun 12, 2009, 12:26:52 PM6/12/09
to
On 6/12/09 4:35 AM, Gervase Markham wrote:

> Please say what the change you are requesting is, and why making it
> would improve your life. References to previous discussions and bug
> numbers would help.

* Remove the Hardware and OS fields:

The Hardware/OS fields are constantly misunderstood or misused: bug-filers
don't know whether they mean "I'm using windows" or "this bug is
windows-specific", and this means that the data is inconsistent, which makes
searching based on the OS/Hardware meaningless. Asking bug filers to fill in
metadata that isn't actually required is an unnecessary burden.

* Remove the severity field

The "blocker" and "enhancement" severities actually mean something to us
currently, but everything inbetween is basically "a bug of some sort"
without much actionable difference. I think we should instead have a
"blocking trunk" flag which we use to mark bugs which should close the
mozilla-central tree, and an enhancement keyword to mark enhancement bugs.

* Combine Status and Resolution

Status and Resolution always come in pairs... it seems silly to have two
fields where one would do quite well.

* Track FIXEDness per-branch

This is by far the hardest and most pie-in-the-sky request, but one which I
think would be most valuable.

--BDS

Mike Shaver

unread,
Jun 12, 2009, 12:29:45 PM6/12/09
to John J. Barton, dev-pl...@lists.mozilla.org
You want those in bugzilla? I'm not sure I want to add build
navigation, but some stuff on the hgpushlog side would be good.

Mike

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

--
Sent from Gmail for mobile | mobile.google.com

Justin Dolske

unread,
Jun 12, 2009, 12:32:00 PM6/12/09
to
On 6/12/09 4:35 AM, Gervase Markham wrote:
> Over the next few months, I will be working on improving
> bugzilla.mozilla.org to better meet the needs of the Mozilla development
> community.[0] I am therefore gathering 'requirements'

I'd like to see improvements to the way reviews are handled. EG,
suggesting appropriate reviewers (perhaps based on some combination of
the bug's component, files in the patch, and reviewer queue length).
Some concept of "next action" could also be useful here, I think Jesse
had posted some ideas about that not too long ago.

Justin

Jesse Ruderman

unread,
Jun 12, 2009, 2:03:28 PM6/12/09
to
I want "next action" and "next action assignee" fields (replacing
several existing fields). Then each contributor will be able to find
bugs they can help with, and fewer bugs will fall into the trap of
being part of an unmanageable "pile of stuff".

Bernd, Chris Lawson, alanjstr, Frederic Wenzel, and Brendan Eich are
all enthusiastically in support of this proposal.

http://www.squarefree.com/2009/04/20/getting-bugs-done/

http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/aa627caed996d9bc

Axel Hecht

unread,
Jun 12, 2009, 4:52:19 PM6/12/09
to

We have a somewhat odd problem in l10n, as we're usually fixing bugs on
branch, and then port to trunk.

So, for new locales, we start working on the 1.9.1 branch, work towards
resolving the bug FIXED there and then need to find a way to track if
the bug is fixed on trunk, too.

I don't really recall what we came up with, I think I personally leaned
towards a "fixed-1.9.2" keyword.

Axel

Blake Kaplan

unread,
Jun 12, 2009, 5:03:38 PM6/12/09
to
Dave Townsend <dtow...@mozilla.com> wrote:
> I'd just remove the version field, it mostly isn't used for anything useful.

As long as we have a way of marking that "this bug only happens on such and
such a branch" I'd support this.
--
Blake Kaplan

Blake Kaplan

unread,
Jun 12, 2009, 5:11:10 PM6/12/09
to
Justin Dolske <dol...@mozilla.com> wrote:
> I'd like to see improvements to the way reviews are handled. EG,
> suggesting appropriate reviewers (perhaps based on some combination of
> the bug's component, files in the patch, and reviewer queue length).
> Some concept of "next action" could also be useful here, I think Jesse
> had posted some ideas about that not too long ago.

Related to this, it might be nice to be able to associate patches with hgweb
revision pages or other ways to track which patches have landed on which
branches. If we did that, it might also be useful to be able to link two
patches as "patch for branch A and patch for branch B."
--
Blake Kaplan

Peter Weilbacher

unread,
Jun 12, 2009, 5:49:36 PM6/12/09
to
On 12.06.09 18:26, Benjamin Smedberg wrote:
> * Remove the Hardware and OS fields:
>
> The Hardware/OS fields are constantly misunderstood or misused: bug-filers
> don't know whether they mean "I'm using windows" or "this bug is
> windows-specific", and this means that the data is inconsistent, which makes
> searching based on the OS/Hardware meaningless. Asking bug filers to fill in
> metadata that isn't actually required is an unnecessary burden.

How then would you discover bugs that are OS dependent? I'm dealing
with them every day, and it would awfully complicate my work if that
field was not there.

As a compromise one could remove the OS and Hardware fields from the
guided form. But then I am not sure how I could reliably search for
all OS/2 bugs that were filed over the last 5 days...

Peter.

Benjamin Smedberg

unread,
Jun 12, 2009, 6:13:42 PM6/12/09
to
On 6/12/09 2:49 PM, Peter Weilbacher wrote:

> How then would you discover bugs that are OS dependent? I'm dealing
> with them every day, and it would awfully complicate my work if that
> field was not there.
>
> As a compromise one could remove the OS and Hardware fields from the
> guided form. But then I am not sure how I could reliably search for
> all OS/2 bugs that were filed over the last 5 days...

I think that specific search requirements can be better met with keywords,
since most bugs are not platform-specific. I think the principle should be
"don't have metadata fields where a keyword will work".

--BDS

Alex Faaborg

unread,
Jun 12, 2009, 6:59:43 PM6/12/09
to dev.planning, Guy Pyrzak, John J. Barton, Jesse Ruderman, Max Kanat-Alexander
Great to hear that you are thinking about making some changes to
bugzilla, I'm cc'ing Max and Guy since they have been in a lot
bugzilla UI discussions with us recently as well.

Two of the previous suggestions that I think would significantly
improve things are John's idea about CC autocomplete, and Jesse's idea
of "next action.

For the autocomplete, it would be even better if we searched against
full name and all associated email addresses on an account, and
started by ranking results with a combination of:

- how active a user is on bugzilla
- how commonly a user is cc'ed on the same bugs as the logged in user
- the context of the specific product and component of the bug

And from that ranking start to bring in some quicksilver / Ed Lee /
adaptive learning awesomesauce.

In terms of Jesse's "next action" idea, the reason I really want this
is to be able to differentiate between bugs that are "uiwanted, but we
are still working on implementation stuff" and "all work has stopped
until the uiwanted keyword is removed." The "next action" field would
of course clear that up significantly, and that's just one specific
example, there are a lot of other cases where it would streamline our
work.

Two new suggestions that I think would also be useful

1 - User Profile Pages. Not in the "turning bugzilla into a social
network for dating" sense, but more being able to navigate on a
particular user and found out how many bugs they have completed, how
many they have filed, what components they generally work in, what
time zone they are in (if they want to disclose it), what their irc
nick is, etc. This could also be a place for people to display any
Friends of the Tree badges they have earned, and the profile system
could almost have a kind of a game design feel. Basically this is
your bugzilla gamertag. Various actions on bugzilla could increase
your gamerscore. Goals of the design could include: making bugzilla
users feel like they are making progress and achieving things by using
the system, improving our view which members of our community are
extremely active and helpful, and overall helping to answer the common
question of "who is [username]?" Note that I am not suggesting that
people would be able to friend each other, only that people could
become friends of particular bugs (we already support this :)

2 - API for accessing the same type of activity that is exposed
through bugmail. I think reading plain text bugmail as an overall
workflow each day isn't very well designed, and it is also something
that many of us spend hours doing. I have a few ideas of how we could
create various Web based interfaces that completely replace the need
for individual bugmail messages, but the first step towards being able
to experiment with new interfaces and workflows is getting access to
the stream of data.

Cheers,
-Alex


On Jun 12, 2009, at 8:38 AM, John J. Barton wrote:

> 1. Support for user-id auto-complete or lookup in the CC field. It
> seems that lots of folks use a different email address in bugzilla
> than they do in email or newsgroups. If you try to CC the other
> address, bugzilla rejects the post because the email address is
> unknown to it.

Daniel Veditz

unread,
Jun 12, 2009, 7:31:20 PM6/12/09
to
Andrew Sutherland wrote:
> 1: Grepping bugzilla trunk, I saw no mention of the
> Access-Control-Allow-Origin header that would allow cross-site XHR in FF
> 3.5, and a quick check against bmo using "wget --server-response" did
> not show the header being introduced by the server either. Just having
> the server enable the header is probably a very wrong thing because of
> the potential horrible cross-site hacks.

As long as it's only returning public data (i.e. XS-XHR without cookies)
I don't see what would be wrong about enabling this. Would not help me
in particular because I deal with a lot of bugs that are restricted to
groups, but could be useful for a lot of other things.

Allowing bugzilla installations to specify "trusted servers" for more
complete sharing could be useful and done safely, but I don't think it
would be useful or safe for the BMO installation.

Daniel Veditz

unread,
Jun 12, 2009, 7:39:05 PM6/12/09
to Gervase Markham
Gervase Markham wrote:
> On 12/06/09 12:49, Axel Hecht wrote:
>> My pet would be a truly-JSON API to get data out of bugzilla. Our use
>> case is the l10n dashboard, which we'd like to have bugilla integrated
>> with.
>
> Is it good enough to have the JSON API have the same capabilities as the
> current query page, or do you need more?

Note that current queries support both XML and CSV output, and the query
request can specify the columnlist you want for the output.

>> too. 75 queries to bugzilla suck, where we'd really want something like
>> "number of open bugs per component in l10n" or "number of open blockers
>> of bugs with an alias matching 'fx35-l10n-.*'"
>
> One additional thing I'll guess you need is an option to return a count
> rather than the bug data?

you can get the count of a single query using ctype=microsummary, but if
you wanted the number "per component" you have to write one query per
component and run each of them separately.

What I think he wants (and if he doesn't I do) is support for GROUP BY.
If we had this feature and it just generated a "group count" column then
we could read the output using the currently supported output formats
(plus JSON if you add a general JSON option).

-Dan

Max

unread,
Jun 12, 2009, 8:09:29 PM6/12/09
to
On Jun 12, 4:49 am, Axel Hecht <l...@mozilla.com> wrote:
> My pet would be a truly-JSON API to get data out of bugzilla.

Bugzilla 3.6 will have a JSON-RPC API that duplicates the XML-RPC
API.

> we'd really want something like
> "number of open bugs per component in l10n" or "number of open blockers
> of bugs with an alias matching 'fx35-l10n-.*'"

You could currently get that data using the CSV format of the tabular
reports, if you want.

> A smaller thing would be to support filling in the alias via the URL.

This should be possible. If it's not, it's a bug.

> I guess that finding out a better way to have "fixed here, but needs
> fixing somewhere else" would be cool, and support for that in queries.

Your current bmo customizations include a "Fixed In" field that isn't
being used.

Otherwise, see here:

https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch

> Shorter query urls by default, maybe.

That is coming in Bugzilla 3.4.

> Better caching? Not sure, but I think we reload a lot these days.

It's a bit tricky to cache bug pages, and impossible to cache bug
searches, and I'm not quite sure what else we would cache that would
have a performance impact.

-Max

Max

unread,
Jun 12, 2009, 8:14:45 PM6/12/09
to
On Jun 12, 9:26 am, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> * Remove the Hardware and OS fields:

Agree. Usually this data is just useful in the description only. I
never have to search or chart against it.

> * Remove the severity field

Disagree. The Bugzilla Project definitely uses this field.

> * Combine Status and Resolution

Unfortunately, RESOLVED FIXED and VERIFIED FIXED mean different
things. For some projects, RESOLVED WONTFIX and VERIFIED WONTFIX also
mean different things. I think there is something to be gained in
workflow for most projects (even if not for Mozilla) from having
separate fields.

> * Track FIXEDness per-branch
>
> This is by far the hardest and most pie-in-the-sky request, but one which I
> think would be most valuable.

You do already have a "Fixed In" field that you can use, if you
want. It's a per-product multi-select field that my company added to
bmo at MoCo's request.

-Max

Max

unread,
Jun 12, 2009, 8:21:28 PM6/12/09
to
On Jun 12, 3:59 pm, Alex Faaborg <faab...@mozilla.com> wrote:
> For the autocomplete, it would be even better if we searched against  
> full name and all associated email addresses on an account,

We do this already, FWIW.

Autocomplete actually isn't even that hard. We just have to find a
good XML-RPC or JSON-RPC client in JavaScript that we can include in
Bugzilla that has a license compatible with the MPL, so that it can
get the data it requires.

> and  started by ranking results

I'd be fine with this as long as the it only sorted people to the
top of they were *significantly* active, and left everybody else in
alphabetical order.

> And from that ranking start to bring in some quicksilver / Ed Lee /  
> adaptive learning awesomesauce.

Sounds cool, but just remember that Bugzilla is not a central,
hosted application where we have total control over the hardware and
scaling (like most Web 2.0 sites), but a shipping app that runs on
single servers. So if we can do this client-side, we're good, but if
it puts too much load on the server-side, it couldn't be supported.

> 1 - User Profile Pages.

bugzilla.gnome.org has describeuser.cgi and we could port something
like that over, upstream. I've often wanted this information in
Bugzilla, myself.

> 2 - API for accessing the same type of activity that is exposed  
> through bugmail.

We actually have a Bug.get_history XML-RPC API method in Bugzilla
3.4 that will let you do this, if you want. It could also be possible
to add an Atom feed, but the data wouldn't be as structured.

-Max

Samuel Sidler

unread,
Jun 12, 2009, 8:21:23 PM6/12/09
to Max, dev-pl...@lists.mozilla.org
On Jun 12, 2009, at 5:14 PM, Max wrote:

>> * Track FIXEDness per-branch
>>
>> This is by far the hardest and most pie-in-the-sky request, but one
>> which I
>> think would be most valuable.
>
> You do already have a "Fixed In" field that you can use, if you
> want. It's a per-product multi-select field that my company added to
> bmo at MoCo's request.

"Fixed In" isn't even close to what we want, unfortunately. This has
been hashed out over and over, so I won't go into detail again, but we
basically need to know the status of bugs across branches, especially
status/resolution. Right now we do that with a mix of keywords and
flags, which sucks in so many ways.

-Sam

Max

unread,
Jun 12, 2009, 8:25:31 PM6/12/09
to
On Jun 12, 5:21 pm, Samuel Sidler <s...@mozilla.com> wrote:
> "Fixed In" isn't even close to what we want, unfortunately. This has  
> been hashed out over and over, so I won't go into detail again, but we  
> basically need to know the status of bugs across branches, especially  
> status/resolution. Right now we do that with a mix of keywords and  
> flags, which sucks in so many ways.

Yeah, I knew all that, but two people on the thread specifically
said, "I want a way to see what branches a bug has been FIXED in", and
that does exist.

-Max

GPHemsley

unread,
Jun 12, 2009, 11:23:50 PM6/12/09
to
On Jun 12, 12:12 pm, Dave Townsend <dtowns...@mozilla.com> wrote:
> On 12/06/2009 17:13, John J. Barton wrote:
>
> > Gervase Markham wrote:
> >> Over the next few months, I will be working on improving
> >> bugzilla.mozilla.org to better meet the needs of the Mozilla
> >> development community.[0] I am therefore gathering 'requirements' -
> >> that is to say,
> > ...
> >> Please say what the change you are requesting is, and why making it
> >> would improve your life. References to previous discussions and bug
> >> numbers would help.
>
> > Remove all of the relative version number aspects of bugzilla, eg
> > 'trunk'. Since some bugs live longer than the binding of 'trunk' to
> > 1.9.1, the word is ambiguous and you always have to double check it.
>
> I'd just remove the version field, it mostly isn't used for anything useful.

This is probably the third discussion that has been had about changes
to BMO and yet still people are suggesting selfish, Firefox-centric
changes. There are a number of projects using BMO that are not related
to Firefox or the Firefox workflow.

The version field is definitely useful when tracking down where a bug
crept in.

The OS/Platform fields could be useful in keeping track of OS-specific
bugs if they weren't automatically set to whatever OS the user
reporting the bug was on. Instead of removing them, they should
default to All/All, so that they have to be purposely changed. Maybe
even exclude them from the reporting form and only allow changes after
the bug has been filed.

It is also very useful to have the severity field, because the
documentation has specific descriptions for what each one means. If
anything should go, it's the priority field, as those are just
arbitrary numbers.

I'm not so sure that it would make sense to combine resolution and
status, either. Especially because of the difference between RESOLVED
and VERIFIED, which can each be use with any of the different
statuses.

As for tracking FIXEDness, I think that's actually the most logical of
the bunch. Assuming, of course, that it'd be customizable per product/
component.

I've got some suggestions of my own, but I had to get this comment in
here before I organized them.

Gordon

John J. Barton

unread,
Jun 12, 2009, 11:38:01 PM6/12/09
to
Mike Shaver wrote:
> You want those in bugzilla?

Well, yes. Changesets should be marked by bugzilla numbers,
changeset-deltas per build should lead to bugzilla numbers per build,
and bugs should record the builds that include the changesets that
support the FIXED claim. There should be an entry in the bug following
FIXED linking the build in red/orange/green according to the unit
tests. If I want to verify the fix, I just click.

jjb

Benjamin Smedberg

unread,
Jun 12, 2009, 11:39:36 PM6/12/09
to GPHemsley
On 6/12/09 8:23 PM, GPHemsley wrote:

> This is probably the third discussion that has been had about changes
> to BMO and yet still people are suggesting selfish, Firefox-centric
> changes. There are a number of projects using BMO that are not related
> to Firefox or the Firefox workflow.

You may take most of the suggestions here as suggestions for what we should
do in Core/Toolkit/Firefox... what happens in other products is probably
best left to the module owners of those products. That there are other
products hosted on bugzilla.mozilla.org shouldn't stop us from improving the
primary problem space.

> The version field is definitely useful when tracking down where a bug
> crept in.

Except we don't use it that way: the field is normally set to the version a
bug was fixed. This is similar for most of the other metadata: it could have
multiple meanings, and getting everyone to agree on a single meaning is
usually not worth the cost of maintaining the metadata.

> The OS/Platform fields could be useful in keeping track of OS-specific
> bugs if they weren't automatically set to whatever OS the user
> reporting the bug was on. Instead of removing them, they should
> default to All/All, so that they have to be purposely changed. Maybe
> even exclude them from the reporting form and only allow changes after
> the bug has been filed.

Yes, there could be value if the field were kept correctly. However, the
cost of maintaining the field, confusing new bug filers, confusing the bug
query forms, etc, is much higher than the potential benefits. We need to
think in cost/benefit terms, not simply whether some field might have some
value.

> It is also very useful to have the severity field, because the
> documentation has specific descriptions for what each one means. If
> anything should go, it's the priority field, as those are just
> arbitrary numbers.

Sure, each value has meaning. But does that meaning cause us to actually
treat the bug differently? I think that other than "blocker", which can
cause the tree to close, in most cases the other values are basically all
treated the same, and it is mainly a source of argument for people who think
the field somehow affects our decision-making.

--BDS

Zack Weinberg

unread,
Jun 12, 2009, 11:43:45 PM6/12/09
to dev-pl...@lists.mozilla.org
GPHemsley <gphe...@gmail.com> wrote:

> This is probably the third discussion that has been had about changes
> to BMO and yet still people are suggesting selfish, Firefox-centric
> changes. There are a number of projects using BMO that are not related
> to Firefox or the Firefox workflow.

Would it be crazy to propose being able to vary the presence
and default state of all the fields on a per-product basis?

zw

GPHemsley

unread,
Jun 12, 2009, 11:52:20 PM6/12/09
to

If all the suggestions you make could be implemented on a product/
component-specific basis, then fine. But the suggestions are not often
made within that context, IMO. I just want to make sure that no one
forgets about the little guys (in my case, Bespin).

Gordon

David E. Ross

unread,
Jun 13, 2009, 1:46:51 AM6/13/09
to
On 6/12/2009 9:26 AM, Benjamin Smedberg wrote [in part]:
> On 6/12/09 4:35 AM, Gervase Markham wrote:
>
>> Please say what the change you are requesting is, and why making it
>> would improve your life. References to previous discussions and bug
>> numbers would help.

The following comments are from the point of view of a user of Mozilla
products, not a developer.


> * Remove the Hardware and OS fields:
>
> The Hardware/OS fields are constantly misunderstood or misused: bug-filers
> don't know whether they mean "I'm using windows" or "this bug is
> windows-specific", and this means that the data is inconsistent, which makes
> searching based on the OS/Hardware meaningless. Asking bug filers to fill in
> metadata that isn't actually required is an unnecessary burden.

If one bug says WinXP and another says Windows XP, I can't do a simple
search and find all the bugs for the same operating system. Having
fields with preset values for OS solves this problem. A similar case
can be made for hardware.


> * Remove the severity field
>
> The "blocker" and "enhancement" severities actually mean something to us
> currently, but everything inbetween is basically "a bug of some sort"
> without much actionable difference. I think we should instead have a
> "blocking trunk" flag which we use to mark bugs which should close the
> mozilla-central tree, and an enhancement keyword to mark enhancement bugs.

Severities are quite well defined and should remain.


> * Combine Status and Resolution
>
> Status and Resolution always come in pairs... it seems silly to have two
> fields where one would do quite well.

One gives the status (Unconfirmed, Resolved, Closed, etc). The other
gives why the bug has that status (Fixed, Wontfix, etc). These should
be kept so that they can be readily seen in a one-line query result
without having to open the bug report.

--
David E. Ross
<http://www.rossde.com/>

Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.

Frédéric Buclin

unread,
Jun 13, 2009, 7:18:41 AM6/13/09
to
Le 13. 06. 09 05:39, Benjamin Smedberg a �crit :

> Except we don't use it that way: the field is normally set to the version a
> bug was fixed.

That's the job of the target milestone field, not the version field. We
(the Bugzilla project) also use the Version field to track when a bug
appeared. This helps us to narrow the regression range. We maintain 4
branches; this information is really important.


> cost of maintaining the field, confusing new bug filers, confusing the bug
> query forms, etc, is much higher than the potential benefits.

There is no cost if projects which don't need these fields ignore them.
There is also no confusion for query forms as long as you don't include
these fields in your queries.


> Sure, each value has meaning. But does that meaning cause us to actually
> treat the bug differently? I think that other than "blocker", which can
> cause the tree to close, in most cases the other values are basically all
> treated the same, and it is mainly a source of argument for people who think
> the field somehow affects our decision-making.

We definitely treat bugs differently based on their severity, both as
reviewers and as developers. The priority I give to a bug marked as
major or critical is completely different from a bug marked as normal or
lower.


LpSolit

Mike Shaver

unread,
Jun 13, 2009, 8:12:40 AM6/13/09
to Frédéric Buclin, dev-pl...@lists.mozilla.org
2009/6/13 Frédéric Buclin <LpS...@gmail.com>:

> There is no cost if projects which don't need these fields ignore them.

How can we hide them, from all bugzilla UI? There is definitely
complexity cost to having more fields in submission, query, and
display.

Mike

Frédéric Buclin

unread,
Jun 13, 2009, 8:16:07 AM6/13/09
to
Le 13. 06. 09 14:12, Mike Shaver a �crit :

> How can we hide them, from all bugzilla UI? There is definitely
> complexity cost to having more fields in submission, query, and
> display.

https://bugzilla.mozilla.org/show_bug.cgi?id=160572
https://bugzilla.mozilla.org/show_bug.cgi?id=449161

Mike Shaver

unread,
Jun 13, 2009, 8:17:00 AM6/13/09
to Frédéric Buclin, dev-pl...@lists.mozilla.org
2009/6/13 Frédéric Buclin <LpS...@gmail.com>:

> That's the job of the target milestone field, not the version field. We (the
> Bugzilla project) also use the Version field to track when a bug appeared.
> This helps us to narrow the regression range. We maintain 4 branches; this
> information is really important.

What do you do if a bug appears in multiple branches, but not all of
them? Similarly with them being fixed? Our branches aren't always
strictly ordered in time (periodic merges between tracemonkey and
mozilla-central are one example), so we can get almost arbitrary
combinations of these characteristics on different branches.

If "target milestone" is what we are Supposed To Use to indicate when
a bug was fixed, why isn't it called "fixed milestone"? That would
certainly have made its proper use clearer to me! (b.m.o's
explanatory link for "target milestone" points at a document dated Jan
1, 2009 that talks about the path to Firefox 2, so we can probably
improve things a bit by explaining it on fields.html and linking
there.)

Mike

Mike Shaver

unread,
Jun 13, 2009, 8:22:21 AM6/13/09
to Frédéric Buclin, dev-pl...@lists.mozilla.org
2009/6/13 Frédéric Buclin <LpS...@gmail.com>:
> https://bugzilla.mozilla.org/show_bug.cgi?id=449161

Does the target milestone on there indicate that it's already fixed in
the bugzilla 3.6 branch?

Mike

Frédéric Buclin

unread,
Jun 13, 2009, 8:29:08 AM6/13/09
to
Le 13. 06. 09 14:22, Mike Shaver a �crit :
> 2009/6/13 Fr�d�ric Buclin<LpS...@gmail.com>:

>> https://bugzilla.mozilla.org/show_bug.cgi?id=449161
>
> Does the target milestone on there indicate that it's already fixed in
> the bugzilla 3.6 branch?

Status is ASSIGNED. So no, it's not fixed yet. This bug is planned to be
fixed in 3.6 before it's released (that's why it's named "target"
milestone).

Mike Shaver

unread,
Jun 13, 2009, 8:36:08 AM6/13/09
to Frédéric Buclin, dev-pl...@lists.mozilla.org
2009/6/13 Frédéric Buclin <LpS...@gmail.com>:
> Le 13. 06. 09 14:22, Mike Shaver a écrit :
>>
>> 2009/6/13 Frédéric Buclin<LpS...@gmail.com>:

>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=449161
>>
>> Does the target milestone on there indicate that it's already fixed in
>> the bugzilla 3.6 branch?
>
> Status is ASSIGNED. So no, it's not fixed yet. This bug is planned to be
> fixed in 3.6 before it's released (that's why it's named "target"
> milestone).

But earlier:

>> Except we don't use it that way: the field is normally set to the version
>> a bug was fixed.
>
> That's the job of the target milestone field, not the version field.

So now I'm confused again -- if the target milestone is used to
indicate the version in which it was fixed, as well as the version in
which it was planned to be fixed, how would we indicate, f.e. "this
was fixed in Firefox 3.5.6, and we plan to also fix it in Firefox
3.0.14"? It's not at all an uncommon situation for us, since
basically every fix that goes into an "older" branch was in a "newer"
branch first.

Not that you guys need to use bugzilla the same way we do, of course,
but if you're going to argue that we're using it wrong, it would be
good to know how using it right might work out better.

Mike

Mike Shaver

unread,
Jun 13, 2009, 8:39:37 AM6/13/09
to GPHemsley, dev-pl...@lists.mozilla.org
On Fri, Jun 12, 2009 at 11:23 PM, GPHemsley<gphe...@gmail.com> wrote:
> This is probably the third discussion that has been had about changes
> to BMO and yet still people are suggesting selfish, Firefox-centric
> changes.

Sure, and you're requesting selfish, Bespin-centric things too.
That's the purpose of the requirements gathering exercise here: figure
out what everyone wants, and *then* we can figure out how to reconcile
it.

TBH, I don't know why Firefox and Bespin need or want to share a
common bugzilla instance -- you're going to have different platforms
of interest (you probably care more about "Browser" than "Hardware"
for narrowing down bugs, for example) and it doesn't seem like we get
much value from being in the same database. If we weren't, then
Bespin folk could also have much wider administrative access to their
instance, making it easier for them to tune configuration and
privileges themselves without needing to worry about Firefox's
security-bug policies and access control.

Mike

Robert Kaiser

unread,
Jun 13, 2009, 9:04:06 AM6/13/09
to
Gervase Markham wrote:
> Please say what the change you are requesting is, and why making it
> would improve your life. References to previous discussions and bug
> numbers would help.

Bug 218917 would really help me, as it would probably also change what
is displayed as the "who" of flags settings. We currently have a good
number of people who are using a bugz...@foo.tld Bugzilla account, and
it's very unhelpful to see "bugzilla: review+" on an attachment.

A faster, more lightweight solution to that may be to have a tooltip
with the full name/mail appearing when mousing over such a shortened
name (usually with flag settings).

A helpful function might also be a possibility to directly forward flags
from an attachment you're obsoleting to the new one you're adding, which
would keep the setter of the flag intact in some way.
The use-case for this is addressing review comments/nits on a patch that
already has reviews, and e.g. still needs super-review or just needed
some small tweak before being checked in and the user requests
checkin-needed on it.

Robert Kaiser

Frédéric Buclin

unread,
Jun 13, 2009, 9:25:29 AM6/13/09
to
Le 13. 06. 09 14:17, Mike Shaver a �crit :

> What do you do if a bug appears in multiple branches, but not all of
> them? Similarly with them being fixed?

It depends on the severity of the bug:
- if a bug is present on all supported branches and trunk, then the
target milestone points to the oldest affected branch which we plan to
fix. It may be the oldest supported branch or not, depending on how
severe the bug is.
- if a bug is only present on some branches but not on the trunk, then
we either mark it as a duplicate of the bug which fixed the problem in
newer branches/trunk if we think the bug is not severe enough to be
backported, or we mark it as WFM if we don't know which bug fixed the
problem on trunk but not on older branches, or we decide to fix it on
older branches and we set the target milestone to the oldest branch we
plan to fix with a comment in the status whiteboard saying [doesn't
affect 3.4 or newer].
- A big difference between the Bugzilla project and Firefox is that we
land all patches at once for all branches. We never land a patch on
trunk if backports are not ready and reviewed. So we don't have this
"FIXED on trunk but not on branches" problem.


> If "target milestone" is what we are Supposed To Use to indicate when
> a bug was fixed, why isn't it called "fixed milestone"?

What is important is the combination of the target milestone + the bug
status. If the bug is still open, then this means that we *plan* to fix
it for the version mentioned in the target milestone. if we miss the
release, then the bug is retargetted. If the bug is FIXED, then this
means that the bug has been fixed in the release mentioned by the target
milestone.


LpSolit

Frédéric Buclin

unread,
Jun 13, 2009, 9:33:31 AM6/13/09
to
Le 13. 06. 09 14:36, Mike Shaver a �crit :

> So now I'm confused again -- if the target milestone is used to
> indicate the version in which it was fixed, as well as the version in
> which it was planned to be fixed, how would we indicate, f.e. "this
> was fixed in Firefox 3.5.6, and we plan to also fix it in Firefox
> 3.0.14"? It's not at all an uncommon situation for us, since

We don't have this problem because we land all backports at the same
time as patches on trunk, so all branches are fixed at the same time. I
agree this is a problem for you.

LpSolit

Joshua Cranmer

unread,
Jun 13, 2009, 9:58:52 AM6/13/09
to
David E. Ross wrote:
> If one bug says WinXP and another says Windows XP, I can't do a simple
> search and find all the bugs for the same operating system. Having
> fields with preset values for OS solves this problem. A similar case
> can be made for hardware.

Most bugs are either immediately seen to be tied to one system (an OS X
address book is obviously OS X-specific code), or are cross-platform.
The setup of the field, however, tends to default to assuming
platform-specific bugs, which is wrong most of the time.

With respect to hardware, I don't see how anyone outside of NSPR or
XPCOM (for the reflection bit) has hardware-specific bugs.

chris hofmann

unread,
Jun 13, 2009, 10:04:46 AM6/13/09
to Mike Shaver, dev-pl...@lists.mozilla.org, Frédéric Buclin

The original intent of target milestone was to provide a planning and
scheduling tool.

The exercise way-back-when was for each engineer to arrange their bugs
distributed over several milestones

beta 1 - bugs x, w, and z
beta 2 - bugs a, b, and c
beta 3 - bugs e, f, and g

The scheduling part of this was to look across the entire project and
all engineers and engineering groups to see which fixes and features
where landing in each milestone. That provided and improved view of
the likelyhood for risk in each beta/milestone, and the also the size
and impact could be roughly derived from the total number of bugs
assigned to each target milestone. When bugs had to be moved over from
one milestone to the next people also started to develop a better sense
of scheduling and which items continued to lag from one milestone to the
next. This also signaled possible risk areas.

Its clear that other uses and explainations for target milestone have
evolved, and we have move away from trying to do this kind of scheduling.

-chofmann

Mike Shaver wrote:
> 2009/6/13 Fr�d�ric Buclin <LpS...@gmail.com>:
>

>> That's the job of the target milestone field, not the version field. We (the
>> Bugzilla project) also use the Version field to track when a bug appeared.
>> This helps us to narrow the regression range. We maintain 4 branches; this
>> information is really important.
>>
>

> What do you do if a bug appears in multiple branches, but not all of

> them? Similarly with them being fixed? Our branches aren't always
> strictly ordered in time (periodic merges between tracemonkey and
> mozilla-central are one example), so we can get almost arbitrary
> combinations of these characteristics on different branches.
>

> If "target milestone" is what we are Supposed To Use to indicate when

> a bug was fixed, why isn't it called "fixed milestone"? That would
> certainly have made its proper use clearer to me! (b.m.o's
> explanatory link for "target milestone" points at a document dated Jan
> 1, 2009 that talks about the path to Firefox 2, so we can probably
> improve things a bit by explaining it on fields.html and linking
> there.)
>
> Mike

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

Peter Weilbacher

unread,
Jun 13, 2009, 11:00:33 AM6/13/09
to
On 13.06.09 00:13, Benjamin Smedberg wrote:
> On 6/12/09 2:49 PM, Peter Weilbacher wrote:
>
>> How then would you discover bugs that are OS dependent? I'm dealing
>> with them every day, and it would awfully complicate my work if that
>> field was not there.
>>
>> As a compromise one could remove the OS and Hardware fields from the
>> guided form. But then I am not sure how I could reliably search for
>> all OS/2 bugs that were filed over the last 5 days...
>
> I think that specific search requirements can be better met with keywords,
> since most bugs are not platform-specific. I think the principle should be
> "don't have metadata fields where a keyword will work".

OK, if I would only ever search for OS/2 bugs, that would work. But keywords
are a mess to search. And as the keyword field already has many uses, adding
more purposes to it will cause it to "overflow" on even more bugs.

I still think that All+All default and hiding on the guided form would solve
most of your problems while retaining their usefulness for all the ports.

Peter.

Peter Weilbacher

unread,
Jun 13, 2009, 11:06:17 AM6/13/09
to
On 12.06.09 13:35, Gervase Markham wrote:
> Over the next few months, I will be working on improving
> bugzilla.mozilla.org to better meet the needs of the Mozilla development
> community.

Great. :-)

> Please say what the change you are requesting is, and why making it
> would improve your life. References to previous discussions and bug
> numbers would help.

I would very much like to be able to search for users from the review
and CC fields. That's bug 91475 which was duped to bug 63689.

Peter.

John J. Barton

unread,
Jun 13, 2009, 11:30:41 AM6/13/09
to
Mike Shaver wrote:
> On Fri, Jun 12, 2009 at 11:23 PM, GPHemsley<gphe...@gmail.com> wrote:
..

>
> TBH, I don't know why Firefox and Bespin need or want to share a
> common bugzilla instance -- you're going to have different platforms
> of interest (you probably care more about "Browser" than "Hardware"
> for narrowing down bugs, for example) and it doesn't seem like we get
> much value from being in the same database.

For what it is worth, our experience: Firebug uses Google-Code for its
own bugs and bugzilla when we want to blame Firefox. At least up till
now the google-code solution has been much simpler for end users, they
don't have to have a degree in Mozillology to report problem. Searching
for "our" bugs is easy and we don't need to compromise on how we use the
tracker. One of the most difficult problems in bug tracking,
uncertain-reply, is reduced by separating the Firebug track from the
Firefox track. The Firebug track is waiting on user info or our action;
the Firefox track is waiting on somebody else and their builds.

jjb

Philip Chee

unread,
Jun 13, 2009, 1:18:27 PM6/13/09
to

Tracemonkey/nanojit recently had a bug that was specific to AMD K-III CPUs.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

David E. Ross

unread,
Jun 13, 2009, 2:29:57 PM6/13/09
to
On 6/12/2009 4:35 AM, Gervase Markham wrote [in part]:
> Over the next few months, I will be working on improving
> bugzilla.mozilla.org to better meet the needs of the Mozilla development
> community.[0] I am therefore gathering 'requirements' - that is to say,
> asking people's opinion about which possible improvements would be most
> useful. This newsgroup post and an associated blogpost pointing here are
> a start; please let me know if there are other forums I could usefully
> ask in.
>
> (I apologise if the reasonably wide crossposting irritates anyone. It
> seems that mozilla.announce has morphed into something which
> non-community-members subscribe to for notification about updates to
> Firefox and Thunderbird, so I suspect it's no longer appropriate for
> this sort of message. Perhaps we need a mozilla.dev.announce.)

>
> Please say what the change you are requesting is, and why making it
> would improve your life. References to previous discussions and bug
> numbers would help.

First attention should be given to bug reports against Bugzilla in
bugzilla.mozilla.org, including RFE bugs. These include the following:

72118 at <https://bugzilla.mozilla.org/show_bug.cgi?id=72118>

133173 at <https://bugzilla.mozilla.org/show_bug.cgi?id=133173>

215588 at <https://bugzilla.mozilla.org/show_bug.cgi?id=215588>

367603 at <https://bugzilla.mozilla.org/show_bug.cgi?id=367603>

Joshua Cranmer

unread,
Jun 13, 2009, 3:15:54 PM6/13/09
to
Philip Chee wrote:
> On Sat, 13 Jun 2009 09:58:52 -0400, Joshua Cranmer wrote:
>> David E. Ross wrote:
>>> If one bug says WinXP and another says Windows XP, I can't do a simple
>>> search and find all the bugs for the same operating system. Having
>>> fields with preset values for OS solves this problem. A similar case
>>> can be made for hardware.
>> Most bugs are either immediately seen to be tied to one system (an OS X
>> address book is obviously OS X-specific code), or are cross-platform.
>> The setup of the field, however, tends to default to assuming
>> platform-specific bugs, which is wrong most of the time.
>>
>> With respect to hardware, I don't see how anyone outside of NSPR or
>> XPCOM (for the reflection bit) has hardware-specific bugs.
>
> Tracemonkey/nanojit recently had a bug that was specific to AMD K-III CPUs.

I forgot that JS now does some pretty hardware-specific stuff.

But my point still remains: most code in mozilla does not have
hardware-specific dependencies and bugs.

Kevin Brosnan

unread,
Jun 13, 2009, 6:56:48 PM6/13/09
to dev-pl...@lists.mozilla.org
I'm wondering why splitting projects to their own Bugzillas has not
entered this conversation. I know there is a whole ton of inertia
against this happening.

The teams working in Bugzilla are using in different ways and getting
bugs from different user bases. I know that a significant percentage
of the Firefox bugs filed are essentially help requests. Where as the
typical Bugzilla bug will have better steps to reproduce and a more
responsive reporter. Trying to appease both of these groups will be
hard.

I would like the ability to take the info from a bug an turn it into a
support.mozilla.org forum post or a newsgroup post. I fee that this
could improve interactions with end users. I encounter reported bugs
in Firefox where it seems the user just wants a fix for an issue.
Often these just languish uncommented on for months till some triager
pokes the bug and resolves it incomplete a several weeks later.

David E. Ross

unread,
Jun 13, 2009, 7:55:04 PM6/13/09
to

The problem is that a bug report against a particular product might
actually be a bug in a different product.

For example, a bug report against Firefox might actually be a bug in
Toolkit. Because of the interface that allows a mailto link in a Web
page to launch an E-mail client, a bug report against Thunderbird might
actually be a bug in Firefox (or vice-versa). The current Mozilla-wide
database of bug reports allows these situations to be handled by merely
changing the product. Separating projects and their products would
require closing the bug for one database and opening a new bug in
another database.

This situation becomes even more cumbersome when the problem lies within
the interface between two products.

Frédéric Buclin

unread,
Jun 13, 2009, 8:19:32 PM6/13/09
to
Le 14. 06. 09 01:55, David E. Ross a �crit :

> This situation becomes even more cumbersome when the problem lies within
> the interface between two products.

Which is why I was discussing with shaver earlier today that some work
in the backend is required first to allow easy move and dependencies
between Bugzilla installations.

LpSolit

Kevin Brosnan

unread,
Jun 13, 2009, 8:33:35 PM6/13/09
to dev-pl...@lists.mozilla.org
The exact location of the spit is not really important at this moment.
Just that it is a an option albeit a difficult one.

For the record I was thinking of a more high level cleave. I agree
splitting out projects that rely on Gecko will result in a lot of
chasing bugs around. However there are a lot of projects/components
that don't rely on Gecko in b.m.o. I would think that there are
similar groupings one could find in the other projects/components.

Rich Gray

unread,
Jun 13, 2009, 11:32:54 PM6/13/09
to
Bug 97956 - Give summary and URL of bugs added or removed from dependencies
in bugmail (notification mail)

<https://bugzilla.mozilla.org/show_bug.cgi?id=97956>

Thanks, Gerv!


--
Rich (Pull thorn from address to e-mail me.)
SeaMonkey - Surfing the net has never been so suite!

Philip Chee

unread,
Jun 14, 2009, 1:01:19 AM6/14/09
to
On Sat, 13 Jun 2009 18:56:48 -0400, Kevin Brosnan wrote:

> I'm wondering why splitting projects to their own Bugzillas has not
> entered this conversation. I know there is a whole ton of inertia
> against this happening.

I've worked on a bug that affected SeaMonkey, Thunderbird, and Firefox
(mostly because we all copied that bug from Firefox). While not
essential it was convenient to work on all my patches in the same bug.
And keeping all the history of the problem in one bug/bugzilla made it
easier to refer to things. Not to mention being able to set cross
product dependencies from say Firefox to SeaMonkey.

Chris Ilias

unread,
Jun 14, 2009, 1:48:36 AM6/14/09