bugzilla.mozilla.org improvements
Gervase Markham
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
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
> 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
> 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.
know if reporter mail not bounced.
Gervase Markham
> 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
> 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
> 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
> 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
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
> 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
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
I'd just remove the version field, it mostly isn't used for anything useful.
Daniel Veditz
> 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
> 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
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
> 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
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
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
> 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
> 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
> * 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
> 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
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
> 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
> 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
> 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
> * 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
> 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
>> * 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
> "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
> On 12/06/2009 17:13, John J. Barton wrote:
>
> >> Over the next few months, I will be working on improving
> >> bugzilla.mozilla.org to better meet the needs of the Mozilla
> >> that is to say,
> > ...
> >> would improve your life. References to previous discussions and bug
> >> numbers would help.
>
> > '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.
>
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
> 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
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
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
> 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
> 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
>
> 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
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
> Over the next few months, I will be working on improving
> bugzilla.mozilla.org to better meet the needs of the Mozilla development
> 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
> 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
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
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
> 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
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
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
> 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
> 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've been using bugzilla for ages, so I'm sure there are things that I
don't even think about, which newer bugzilla users have issues with.
With that said...
* If I'm reading a bug report for the first time, and trying to
familiarize myself with what has happened on the bug so far, it's hard
to know what actions in the bug comments correspond with what action in
the bug history (renaming, changing component, change of status, etc.).
If you could incorporate bug history and bug comments[1], it would make
it much easier to put the bug history and comments into context.
[1] with the obvious exception of people adding themselves to the CC list.
* The ability to subscribe to keywords. For example, if someone adds the
user-doc-needed keyword to a bug, I'm not aware of it until the next
time I do a search for user-doc-needed bugs. Expanding this issue to
more than just keywords, perhaps having something like Google alerts for
bugzilla queries would help contributors stay on top of recent changes.
* As KaiRo touched on, we don't always know each contributors' email
address. If I want to add someone to a bug or assign it to someone, I'd
like to be able to enter their name, instead of having to search for
their email address.
Robert O'Callahan
> 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.
Something simple that I think would help here, and that I've been asking
for for years, is for Bugzilla to know which people can accept review
and super-review requests, and to require review/sr requests to be
directed to those people. This would prevent the infamous "review
request with no requestee" and "review request to someone totally
random" problems. It would also make autocomplete much more accurate.
To minimize management issues, I think each person should be able to
specify in their Bugzilla profile whether they're accepting
reviews/super-reviews. Bug 242194 is basically about this, although I
think it would be best to have thse bits off by default. People who are
accepting review/sr requests should know to turn these bits on.
Rob
Robert O'Callahan
would significantly improve my productivity if Bugzilla minimized the
number of page reloads using AJAX techniques. Page loads are on the
order of seconds from NZ. From pressing "Commit" to the reloaded page
finishing loading can easily take ten seconds even on a good day, and I
do this *a lot*.
So, it would be amazingly great if each "commit" just sent a message to
the server, updated the bug in-place and displayed something to let me
know when that message has been acked so I can close the window, move
onto the next bug, etc. It would be great if that worked for attaching
patches and modifying patch state too.
Rob
Bradley Baetz
> Something simple that I think would help here, and that I've been asking
> for for years, is for Bugzilla to know which people can accept review
> and super-review requests, and to require review/sr requests to be
> directed to those people. This would prevent the infamous "review
> request with no requestee" and "review request to someone totally
> random" problems. It would also make autocomplete much more accurate.
Bugzilla can already require requstees to be in a specific group. The
group is per flag, but if you want different reviewer groups per product
then you can just set up extra flags (this is already done for some
products). That doesn't flow through into the autocomplete stuff.
There's nothing that allows a flag to be marked as requiring a
requestee, though.
> To minimize management issues, I think each person should be able to
> specify in their Bugzilla profile whether they're accepting
> reviews/super-reviews.
https://bugzilla.mozilla.org/userprefs.cgi?tab=flags (bmo customisation,
not upstream) Again, per flag not per product.
Bradley
timeless
> 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.
various random pieces of firefox FE code have #ifdef PLATFORM
there are also random surprises such as when a platform (osx) does
something strange to widgets (sheets).
then there's plugins, and event loops, and reentrancy.
i love it when people say " oh, we don't need this".
The Apple devs insisted we didn't need the OS Minor Version in their useragent.
As a result, Google offers people Firefox 3 when they visit it w/
Firefox 2 on 10.3.9. This of course fails miserably.
Optimizing things is always fun especially when you don't have to
clean up the pieces.
Personally I'd prefer to collect as much information as possible, but
change the default presentation and search behaviors.
FWIW, the Hardware chipset surprise is the third or fourth time we've
seen this sort of problem. There was an exciting locking issue on
multicore apple computers (intel hardware) that also turned up in JS
land. The code was technically broken anywhere that certain rules
didn't hold, but apple's hardware was the first such major place where
we encountered it.
We've also had a bunch of fun problems in image decoding (usually we
wisely give up on even bothering to specialize that code, as it always
ends up in headaches, but people don't learn and keep trying).
timeless
this doesn't even address all the external dependencies, right now i
can pass around a single string 'bug 10020' and it's meaningful for
anyone in mozilla.org.
If we have 20 bugzillas (some of which will die and move and ...) then
i'll have to write 'foopy bug 1012', and if someone forgets the
'foopy', it's useless. more fun, someday someone will rename 'phoenix'
to 'firebird' to 'firefox' and i'll have a phoenix bug 203, which
might really be firebird bug 182 or firefox bug 320, or maybe all
three bug databases will be dead and lost.
being able to move bugs from database to database is a prereq, but it
isn't sufficient, and relying on it shouldn't be the obvious choice.
there are already too many ways for bugs to get lost. do you think
people enjoy trying to chase down the right vendor reporting system? i
do not want someone to say 'oh, i reported that critical vulnerability
to the mozilla snoopyfox project, and it wasn't handled' when in fact
it was a bug in NSS or XPCOM or PSM or whatever and because the devs
for those systems don't snoop hundreds of related bugzillas, they
didn't get the report.
timeless
> * As KaiRo touched on, we don't always know each contributors' email
> address. If I want to add someone to a bug or assign it to someone, I'd like
> to be able to enter their name, instead of having to search for their email
> address.
So, if you're using the CC list of a live bug, you can do:
@ timeless
and press enter, and bugzilla will offer matches for 'timeless'.
as long as you're not filing a bug or adding an attachment, this will work.
you can also use this feature for assignees, qa contacts and
requestees. however using '@' as an extra value only works in the CC
field and lets you avoid accidentally selecting the wrong person.
you can stick as many partial names into the cc field as you like,
space separated.
Chris Ilias
> So, if you're using the CC list of a live bug, you can do:
>
> @ timeless
>
> and press enter, and bugzilla will offer matches for 'timeless'.
>
> as long as you're not filing a bug or adding an attachment, this will work.
>
> you can also use this feature for assignees, qa contacts and
> requestees. however using '@' as an extra value only works in the CC
> field and lets you avoid accidentally selecting the wrong person.
>
> you can stick as many partial names into the cc field as you like,
> space separated.
Thanks!
Benjamin Smedberg
> 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 think we should try to use keywords as much as possible (they are tags,
essentially): what are you worried about in terms of "overflow"? That it is
harder to search on keywords, or they don't all appear in the keywords field
in the UI, or something else? I bet we could fix that very simply, and it
would still be better than having a bunch of always-displayed fields.
--BDS
Benjamin Smedberg
>> 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.
Whether you could have an arch-specific or OS-specific or whatever-specific
bug is irrelevant. Each metadata field has a mental cost at bug-filing,
bug-viewing and bug-searching time. If we can make most metadata disappear
by default and only have that metadata appear if it's actually relevant *and
necessary*, we'll reduce the complexity of our system.
Let's say we have ARM-specific bugs and AMD K-III-specific bugs: we need to
decide:
* do we need to be able to find this bugs as a class? If not, we don't need
any metadata at all. As an example, I suspect that at the moment we need to
be able to find all ARM-specific nanojit bugs, but not all AMD
K-III-specific bugs.
* Can we use a optiona, lightweight mechanism like keywords instead of a
required, heavyweight solution like an extra field to solve the problem? The
fewer fields that are displayed by default in the bug-filing, bug-view and
bug-search forms, the more likely we are to actually have correct data.
--BDS
David E. Ross
Keywords are useless if not standardized. You can't get all the
Thunderbird bug reports by searching keywords if someone has used
"TBird" instead of "Thunderbird".
Declaring a standard won't work unless it's enforced by having all
keywords selectable from a pull-down list and none allowed to be typed
into an input field. Such a pull-down list could easily become far too
long unless divided into sublists. But that's the existing capability,
with the pull-down lists divided between different fields.
Smokey Ardisson
> * Can we use a optiona, lightweight mechanism like keywords instead of a
> required, heavyweight solution like an extra field to solve the problem? The
> fewer fields that are displayed by default in the bug-filing, bug-view and
> bug-search forms, the more likely we are to actually have correct data.
I like to be able to (weekly, every-couple-of-days) check in on Mac-
specific bugs in cross-platform components where my platform-specific
knowledge can be helpful with triage and QA (and also for learning of
new bugs of this sort that affect me), so right now I have queries for
Thebes and Plug-ins where the OS is Mac OS X. Except these components
often get Windows or Linux bugs filed by Mozilla developers with OS =
Mac OS X, and I regularly find by other means bugs affecting only Mac
OS X that have OS = Windows or OS = Linux. (This describes the current
problem, that the value of these fields is sometimes wrong when
Mozilla developers file bugs--all the bugs coming in out of
Firefox:General have typically been set correctly by the bug reporter
or the triager).
My concern is this: if we can't rely on Mozilla developers to set the
correct OS metadata for OS-specific bugs in cross-platform components
when *the field already exists*, how are we going to get these same
people (and everyone else filing bugs) to set the correct metadata
when relevant when there's no dedicated field to prompt them to do
so? How are Peter and I and other people who have interest in OS (or
hardware) bugs ever going to find those bugs without going through
every single newly-filed/moved bug ourselves? Moreover, instead of
triage having to simply show a negative ("I see this on Linux, too;
it's not Mac-only"), triage would now have to prove a positive ("This
doesn't happen for me on Linux, but I don't have Windows; can someone
else please check Windows to see if this is Mac-only or not?") before
making sure that a OS-specific bug gets seen as such by people with
platform knowledge.
Right now these fields provide value some of the time and largely do
no harm the rest of the time; I think it's a lot easier to flip a bug
to All/All than it is to take a bug with no metadata (and no specific
field for that metadata), determine that it's a platform-specific bug,
and tack yet another keyword into the Keywords field.
Max
> * If I'm reading a bug report for the first time, and trying to
> familiarize myself with what has happened on the bug so far, it's hard
> to know what actions in the bug comments correspond with what action in
> the bug history (renaming, changing component, change of status, etc.).
> If you could incorporate bug history and bug comments[1], it would make
> it much easier to put the bug history and comments into context.
That's this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=11368
> * The ability to subscribe to keywords.
That's this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=278455
> perhaps having something like Google alerts for
> bugzilla queries would help contributors stay on top of recent changes.
That already exists, it's called "Whining".
> * As KaiRo touched on, we don't always know each contributors' email
> address. If I want to add someone to a bug or assign it to someone, I'd
> like to be able to enter their name, instead of having to search for
> their email address.
As others have pointed out, you can.
-Max
Max
> So, it would be amazingly great if each "commit" just sent a message to
> the server, updated the bug in-place and displayed something to let me
> know when that message has been acked so I can close the window, move
> onto the next bug, etc. It would be great if that worked for attaching
> patches and modifying patch state too.
For what it's worth, if that's taking 10 seconds, it's most likely
latency between you and California, and it would probably take 10
seconds with AJAX, as well. It might shave off a little bit of time
(maybe 2 seconds?) but if performance over the ocean is the real
problem, the real solution is to figure out how to do long-distance
MySQL slaves (or possibly long-distance MySQL multi-master) and web
heads with Bugzilla (which unfortunately is probably far more complex
than implementing AJAX).
-Max
Boris Zbarsky
> Declaring a standard won't work unless it's enforced by having all
> keywords selectable from a pull-down list
Which they are (or rather an autocomplete list).
> and none allowed to be typed into an input field.
Which they're not. Or rather, you can type them, but the submit will
fail unless what you typed is in the list.
Have you actually _tried_ using keywords in our current bugzilla? Or
are you perhaps thinking of the status whiteboard, which is a totally
different thing?
-Boris
Robert Kaiser
> 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 painfully learned today that mass-changes are quite slow (I did a
status change and a comment post) right now in our Bugzilla, possibly
running into Apache timeouts that result in "This document contains no
data" in the browser (which made me think the process failed and made me
re-submit it, when actually it was still running to completion in the
background - welcome double-/multi-comments).
it would be good to find a way that 1) those changes are faster, 2) that
Bugzilla warns you or Apache doesn't time out when it's actually that slow.
Robert Kaiser
P.S.: I'm deeply sorry for any double or multiple comments and bugmails
I caused today, I surely didn't want that to happen.
Mike Shaver
> On 6/13/2009 3:56 PM, 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.
>
> actually be a bug in a different product.
>
> For example, a bug report against Firefox might actually be a bug in
> Toolkit.
Or in sqlite or cairo or the Windows SDK or CoreGraphics or ...
> 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).
Or in Internet Explorer or Safari or Outlook.
> The current Mozilla-wide
> database of bug reports allows these situations to be handled by merely
> changing the product.
..and converting the blocking flags, and figuring out what to do with
patch flags that are per-product, etc.
I don't think there's any more likelihood that a bug in Bespin needs
to be moved to Firefox's product than that it needs to be moved to
Apple's Radar. Let's optimize for the common case.
Mike
Roy Mercon
have no idea what you guys are talking about, and I can't seem to be
able to figure out how to get off this list. Can someone help me out?
Thanks. Sorry to interrupt what I think is a coversation that is going
to better the world. Firefox is awesome.
Pfc. Roy Mercon
Public Affairs Specialist
Vermont Army National Guard
Phone: (802) 473-0083
On Jun 14, 2009, at 20:17, Mike Shaver <mike....@gmail.com> wrote:
> On Sun, Jun 14, 2009 at 8:12 PM, Mike Shaver<mike....@gmail.com>
> wrote:
>> On Sat, Jun 13, 2009 at 7:55 PM, David E. Ross<nob...@nowhere.not>
>> wrote:
>>> For example, a bug report against Firefox might actually be a bug in
>>> Toolkit.
>>
>> Or in sqlite or cairo or the Windows SDK or CoreGraphics or ...
>
> Though I'm not suggesting that we split Firefox and Toolkit to
> seperate installs. The splitting has been in reference to the vastly
> different workflows and meanings that are used by, f.e., Bespin and
> Bugzilla-the-project, which keep coming up in this thread as reasons
> to not make the changes that are being requested for Firefox or other
> related applications.
Benjamin Smedberg
> Right now these fields provide value some of the time and largely do
> no harm the rest of the time; I think it's a lot easier to flip a bug
> to All/All than it is to take a bug with no metadata (and no specific
> field for that metadata), determine that it's a platform-specific bug,
> and tack yet another keyword into the Keywords field.
Assuming we follow the advice of others to make it default to All/All
instead of auto-detecting, how is that better than a keyword?
I think you underestimate the harm of all the fields at the top of a bug:
they are visual clutter which we have gradually learned to tune out, but I
know that I spent my first year of Mozilla searching for Windows bugs only
to learn that most Windows bugs were actually OS==All.
To put it another way: do you think it's valuable enough to make everybody
spend time thinking about whether a bug is platform-specific or neutral (or
not understanding what we're asking) in order to make life easier for you
and Peter, or the small set of people who want to categorize bug queries by OS?
--BDS
Rich Gray
> Assuming we follow the advice of others to make it default to All/All
> instead of auto-detecting,
Wouldn't Unspecified/Unspecified be a better default. Then All/All
would be an indicator that someone is explicitly saying that this
is a cross-platform bug.
Honestly, as someone who is still not really in the thick of things
and still sometimes has a hard time with Bugzilla, I feel much more
comfortable with the OS/Hardware fields than keywording them. Yes,
all that stuff at the top is still somewhat intimidating to me, but
I think I'd rather have it than not. My biggest problem is still
trying to figure out component/product/trunk/branch for searches. :/
David E. Ross
> 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.
1.
Does the Bugzilla database and query system support indexing? That is,
if a particular field can have only unique data (i.e., the bug number),
will a query in that field operate more quickly than a query on a field
where more than one bug can have the same data?
I'm not really familiar with the query system in Bugzilla. I know that
Oracle's QMF/SQL supported indexing a number of years ago.
I ask about this because it seems that a query only on bug numbers seems
to take too long to produce results. It seems to take as long as
queries on other fields. If indexing is supported but not implemented,
it really should be implemented.
2.
I have to login to request one of my saved queries. When I finally get
a list of bugs, it takes a long time to get individual bug reports when
I select some of the bugs from my query. Generally, I merely want to
see the current status of the bugs and review new comments. Part of the
delay is caused by the fact that the bug reports involve Web forms for
modifying the reports, which take longer to download than simple
read-only bug reports.
It would be nice if I could check a checkbox on the list generated by my
query to get simple read-only bug reports. If I see a bug report that I
then want to modify, selecting the link for that report (near the
top-left) could then give me the report with Web forms for inputs. This
would require (a) producing reports that appear as if I were not
logged-in if the checkbox is checked and then (b) using the link on the
report itself to ignore that checkbox (which would not even be on that
page).
Axel Hecht
> 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).
Yep, group-by is what I'm thinking of.
In particular for l10n, finding the 80+ components is really tedious.
Let alone waiting for all the queries to return. Let alone that in the
bug UI that I did so far, I used the js api, which restricts me to a
single query at any point in time. Ugh, that was slow for only a handful
of queries.
Axel
Bradley Baetz
> 1.
>
> Does the Bugzilla database and query system support indexing? That is,
> if a particular field can have only unique data (i.e., the bug number),
> will a query in that field operate more quickly than a query on a field
> where more than one bug can have the same data?
Yes - it uses mysql.
> I ask about this because it seems that a query only on bug numbers seems
> to take too long to produce results. It seems to take as long as
> queries on other fields. If indexing is supported but not implemented,
> it really should be implemented.
There are a couple of issues. One is that there are additional security
checks that check that the bug isn't a security bug/etc.
Also, its possibly *perceived* as slow, because an unfortunate
sideeffect of using the templating language (template toolkit) is that
all output is buffered, so the webserver isn't able to send any of the
content until after the page finishes. However, even if it did (and bmo
has in the past had some local hacks/patches to flush content more
often) it wouldn't help bug lists - mysql doesn't support cursors, so
any select result has to entirely be pulled out of the DB, so it
wouldn't be possible to display the output as it comes anyway.
(I tried doing some quick tests now, but my ISP seems to be having DNS
issues at the moment. I tested on a local install, though, and did find
one perf issue which I'll file)
> 2.
>
> I have to login to request one of my saved queries. When I finally get
> a list of bugs, it takes a long time to get individual bug reports when
> I select some of the bugs from my query. Generally, I merely want to
> see the current status of the bugs and review new comments. Part of the
> delay is caused by the fact that the bug reports involve Web forms for
> modifying the reports, which take longer to download than simple
> read-only bug reports.
It shouldn't. I guess the page is slightly bigger, but it shouldn't be
noticeable unless you're on a slow connection (and I say this as someone
with a 170ms RTT to bmo) I did a few quick wget tests with and without
being logged in and didn't see any noticable difference. Its possible
that the mozilla webcaches are set up to cache pages for non logged in
users, though.
> It would be nice if I could check a checkbox on the list generated by my
> query to get simple read-only bug reports. If I see a bug report that I
> then want to modify, selecting the link for that report (near the
> top-left) could then give me the report with Web forms for inputs. This
> would require (a) producing reports that appear as if I were not
> logged-in if the checkbox is checked and then (b) using the link on the
> report itself to ignore that checkbox (which would not even be on that
> page).
There is the 'format for printing' option, but that shows everything
you've found, not a subset.
Bradley
Robert O'Callahan
> On Jun 13, 11:01 pm, Robert O'Callahan<rob...@ocallahan.org> wrote:
>> So, it would be amazingly great if each "commit" just sent a message to
>> the server, updated the bug in-place and displayed something to let me
>> know when that message has been acked so I can close the window, move
>> onto the next bug, etc. It would be great if that worked for attaching
>> patches and modifying patch state too.
>
> For what it's worth, if that's taking 10 seconds, it's most likely
> latency between you and California,
Ping times between here and California are around 200ms (round trip).
> and it would probably take 10
> seconds with AJAX, as well. It might shave off a little bit of time
> (maybe 2 seconds?) but if performance over the ocean is the real
> problem, the real solution is to figure out how to do long-distance
> MySQL slaves (or possibly long-distance MySQL multi-master) and web
> heads with Bugzilla
I don't think so. Some AJAX apps hosted in California, like Mozilla's
Zimbra server, are much more responsive.
I'm not sure what the problem is exactly. It takes multiple seconds from
pressing "Commit" to the new page starting to appear, and then it takes
multiple seconds for that page to fully load. Sometimes it is faster
though. Maybe it's a congestion problem and we'd do better by sending
short messages --- Bugzilla show_bug.cgi pages are pretty large.
Rob
Axel Hecht
> 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?
>
I guess for l10n, the biggest thing would be group-by. Generally though,
wouldn't we try to keep the features of the queries up to par for the
different output methods?
Axel
Eddy Nigg
> 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.
>>
> 1.
>
> Does the Bugzilla database and query system support indexing? That is,
> if a particular field can have only unique data (i.e., the bug number),
> will a query in that field operate more quickly than a query on a field
> where more than one bug can have the same data?
>
Looking at our Bugzilla DB it clearly has primary indexes and indexed
fields. Some indexes might not be unique, but the primary key can only
be unique, so not sure where the slowness you experience comes from.
Actually I'd be very surprised if Bugzilla wouldn't index fields.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Archaeopteryx
- Easier/more integrated tagging system: If I want to do something with
a bug in the future (close if no response, work on it, see it fixed),
I'd like to define a tag (maybe bound to product and even component) and
if that tag exists and the bug product matches the one of the tag, there
should be a checkbox "Add to <tagname>". Tag based mail preferences and
auto hiding fixed bugs (or with responses etc.) would also be nice.
- I'd like to organize the order of my safed searches.
Archaeopteryx
Gervase Markham
> 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.
I would _hope_ that the charts a particular person gets are reflective
of the bugs that person can see, and if there were a loginless version,
it would reflect the bugs anyone can see. If that's not true, that's a bug.
Gerv
Gervase Markham
> Mike Shaver wrote:
>> You want those in bugzilla?
>
> Well, yes. Changesets should be marked by bugzilla numbers,
The checkin comment should have the bug number; if it doesn't, politely
email the developer to ask why not.
> changeset-deltas per build should lead to bugzilla numbers per build,
And so from the checkin comments for "new in this cycle" checkins on
tinderbox you can see what has changed
> and bugs should record the builds that include the changesets that
> support the FIXED claim.
I don't quite understand what you are asking for. How is it helpful for
every fixed bug to say "this fix was first included in build X", where
build X is always the next nightly after the checkin time?
> 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.
That doesn't verify the fix, it verifies that the fix builds and the
unit tests run. That's not the same thing :-)
Also (see other parts of this thread) some bugs are checked in on
multiple branches.
Gerv
Gervase Markham
> As long as we have a way of marking that "this bug only happens on such and
> such a branch" I'd support this.
But isn't that the current use for the "version" field?
Gerv
Gervase Markham
> * 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 the fields are still used for tracking e.g. Windows-specific bugs,
would removing them from the bug-filing process achieve the same end
while preserving that ability? That is to say, have these two fields set
on all initially-filed bugs as All/All? Then, if the bug is
Windows-specific, it can be manually set later by someone competent.
> * 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.
Do individual developers use this field at all?
> * Combine Status and Resolution
>
> Status and Resolution always come in pairs... it seems silly to have two
> fields where one would do quite well.
This effect is IMO currently achieved fairly well using JavaScript in
the current b.m.o. UI. I.e. you don't care about Resolution until you
set Status to Resolved, and then the dropdown appears. I guess a
combined dropdown would be one less click, but the list of choices would
be longer.
> * 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.
Yes, indeed, on both counts :-)
Gerv
Gervase Markham
> 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.
Indeed. The idea that "if the bug is open, Target Milestone is the
version we hope to fix it in, and if the bug is fixed, Target Milestone
is the version we actually did fix it in" works great in a one-branch
system, but when you have multiple branches where you check in on each
at different times, it doesn't.
Gerv
Gervase Markham
> Would it be crazy to propose being able to vary the presence
> and default state of all the fields on a per-product basis?
It's not crazy to propose it :-)
Gerv
Gervase Markham
> TBH, I don't know why Firefox and Bespin need or want to share a
> common bugzilla instance
I think one of the important things we are going to have to decide is
what variations it makes sense to try and support within a specific
Bugzilla instance (e.g. per-product) and what variations mean that the
requirements are different enough that what you really want is a
specifically-customised instance for that product, project or group.
I guess this will involve trying to see if it's possible to put all our
different projects into a small number of groups based on their style of
Bugzilla usage. And dealing with the fact that there's shared code.
It may be, for example, that the products based on the core should be in
one database, web-based things (websites, webtools) in another, and
admin stuff (legal, marketing) in yet another. One possibility is to run
multiple Bugzilla software installations against the same database. So
you _could_ view a Firefox bug via the Website Bugzilla, but the UI
would be weird and you might not see all the fields...
Gerv
Gervase Markham
> 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.
That is why it is proposed that the replacement would be keywords, for
which specific values are defined.
Gerv
Gervase Markham
> 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.
That sounds like a great job for a Greasemonkey script. :-)
Gerv
Gervase Markham
> So, I got put on this mailing list, and I have no idea how or why. I
> have no idea what you guys are talking about, and I can't seem to be
> able to figure out how to get off this list. Can someone help me out?
> Thanks. Sorry to interrupt what I think is a coversation that is going
> to better the world. Firefox is awesome.
Hey Roy,
In the footer of every message is a link:
>> dev-planning mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-planning
which takes you where you need to go to unsubscribe.
Gerv
Gervase Markham
> - Easier/more integrated tagging system: If I want to do something with
> a bug in the future (close if no response, work on it, see it fixed),
> I'd like to define a tag (maybe bound to product and even component) and
> if that tag exists and the bug product matches the one of the tag, there
> should be a checkbox "Add to<tagname>".
I believe you can define a saved search and add bugs to it, although
I've not used this feature. Does it do what you want?
> - I'd like to organize the order of my safed searches.
If you have that many, and you aren't sharing them with anyone, have you
considered bookmarks?
Gerv
Gervase Markham
> P.S.: I'm deeply sorry for any double or multiple comments and bugmails
> I caused today, I surely didn't want that to happen.
Hey, it happens :-) The funniest thing was that in a couple of cases I
saw, people reset the bugs to NEW saying "I still see this" and then you
came along again and reset them to UNCO ;-)
Gerv