bugzilla.mozilla.org improvements

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
0
Gervase
6/12/2009 11:35:05 AM
mozilla.dev.apps.thunderbird 3464 articles. 0 followers. Post Follow

253 Replies
1885 Views

Similar Articles

[PageSpeed] 6

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
0
Axel
6/12/2009 11:49:07 AM
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 :)
0
Dave
6/12/2009 12:10:15 PM
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.
0
Nikolay
6/12/2009 12:35:13 PM
On 06/12/2009 01:35 PM, 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, 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.
Hi Gervase!
One of the things I like with the GNOME bugzilla is that the attachment 
column makes better use of the screen width.
Mozilla: http://www.andreasn.se/diverse/temp/bugzilla-mozilla.png
GNOME: http://www.andreasn.se/diverse/temp/bugzilla-gnome.png
- Andreas
0
Andreas
6/12/2009 12:39:26 PM
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, 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.

collapse all the non-requried and less-frequently used fields by 
default.  This would simplify the layout of bug reports and make it less 
daunting for new participants.  We've started doing that with Collapse 
All Comments/Expand All Comments but thats probably the least valuable 
thing to be expanding/collapsing.  the comments are the "meat and 
potatoes" of the bug content.   lets expand/collapse all/most of the 
other stuff by default, and allow user prefs to control what gets 
expanded and collapsed by default for each user.   This kind of layout 
would turn bug into something that looks more like a forum post and be 
more familiar and less daunting for new users to bugzilla, and it would 
also streamline navigation of bug pages for advanced or frequent 
bugzilla users.  Imagine the number of saved scroll clicks if we did 
something this ;-)

-----------------------------------------------------------------------------------------

 Bug 666666 -  simplfy bugzilla bug form layout

+ reported by [chofmann]  cc list
+ history
+ product, component, keywords...
+ prority severity
+ status [new]
+ depenencies
+ flags  [no flags are set on this bug]
+ visibility / viewing restrictions
+ attachments
- Comments  [link to last comment]

    collapse a lot of less frequently make it look more like a forum or 
blog post

comment #1

    also safe users prefs so they can have the default view of what 
fields they want to have open

addtional comments
 ___________________________________________   
|
|   this is my new comment that I'm about ready to post...
|
|
____________________________________________

[commit]


>
> 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
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps-firefox@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
0
chris
6/12/2009 12:44:13 PM
On Fri, Jun 12, 2009 at 7:35 AM, Gervase Markham<gerv@mozilla.org> wrote:
> (I apologise if the reasonably wide crossposting irritates anyone.

It will split the conversation for people using the mailing lists, if
nothing else.  (I saw this in dev-quality, others seem to have seen it
in other groups; I doubt we'll all see each other's replies.)

> Perhaps we need a mozilla.dev.announce.)

I think we generally use .planning for that, these days.

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

Thanks for taking this on!

Let me first say that I don't want any changes to the bugzilla UI.
Firefox's needs are clearly sufficiently different from the rest of
the world's that accommodating them is painful and invasive.  I just
want the tools to build a UI and workflow that suits us.

- a full REST+JSON API, so that anything currently possible through
the bugzilla web UI (read or write) can be done through another
program on another server

- server-side hooks for basically every action, so that f.e. I could
write something that did component watching the way I want without
having to even discuss it with upstream, let alone make it
sufficiently general to be accepted.

- fixed mid-air collision handling, such that
 = there are no more false positives (mid-airs that don't actually over-write)
 = changes to unrelated fields do not conflict
 = changes to related fields are resolved "humanely" (if I added a
dependency, and someone else removed another, those are not hard to
reconcile)

- ability to do historical queries on bug attributes ("what were all
the bugs with blocking-firefox3.5+ on Friday?") so that people can
stop scraping daily queries or trying to figure out the charting
system

- no mandatory fields, all fields should be able to be multi-valued
(this would let us solve the resolved-vs-fixed-keyword problem, as
well as "vista and win7 but not win XP", and would let us have bugs in
multiple components, multiple assignees for bugs, etc. -- we can argue
about whether we want to permit that in different parts of our product
as a matter of policy, but the mechanism should be there)

- support for parallelizing queries across multiple servers, since
mining this data will become increasingly resource-intensive once we

- intelligent caching of API and web-UI results, based on modification
time for bugs; "generate on change" via the server side hooks would be
a DIY option, certainly

- ability to orphan components/bugs/flags/etc. without a ton of noise.
 I should be able to make "fixed1.4.1" never show up in the keyword
autocomplete without having to do a pile of bug-munging.

configuration changes:

- at least 80% fewer components, and many fewer products.  We have 8
different DOM components, but nowhere obvious to put postMessage; 7
Java-related components; 12 different layout components; SQL (not
supported anywhere, and not related to our own sqlite use or APIs); 9
different widget components, etc. -- and that's just Core.  Mostly
these subdivisons seem to be used as ways to narrow queries or get
bugmail people want, all of which I think would be done better through
attribute-based notifications/queries instead of something between the
reporter and the bug.  (I routinely have to take an entire minute just
to figure out what product+component I want to file a bug, and I
usually already know what code it's in!)

- remove platform and OS, use keywords for them instead (until the
multi-value thing is resolved above)

- when I'm filing a bug, the text area in which I am to describe the
bug should be above the fold.  Everything else (including the
component it's in) is subsidiary to the bug description itself, and
should be farther down (or invisible -- why do I care who the default
CC: is? why would I ever change the QA contact?)

Mike
0
Mike
6/12/2009 1:07:39 PM
I would like to see someone finish (or rewrite) the patch I attached to bug
386600 - JavaScript autocomplete for review request field. For bonus points,
the same backend code should be used anywhere else that you currently enter
someone's bugmail in the UI. I waste an awful lot of time guessing at
people's bugmail.

-Ted
0
Ted
6/12/2009 1:26:07 PM
On Fri, Jun 12, 2009 at 9:26 AM, Ted Mielczarek<ted.mielczarek@gmail.com> wrote:
> I would like to see someone finish (or rewrite) the patch I attached to bug
> 386600 - JavaScript autocomplete for review request field. For bonus points,
> the same backend code should be used anywhere else that you currently enter
> someone's bugmail in the UI. I waste an awful lot of time guessing at
> people's bugmail.

Relatedly, people should be able to hide their accounts from
auto-completion or partial matching.  That would let us get rid of the
poorly-named noise from gmail watcher accounts.

(Autocomplete of usernames might be best if it only matched against
people who had ever been put in a cc: field by someone other than
themselves, not counting cloning or duping.)

Tip for people creating gmail watcher accounts: don't put your ircnick
or email prefix in the name! bugmail-as@gmail.com with forwarding
instead of asmith@gmail.com avoids the collision entirely.  And,
obviously, don't put "not asmith's bugmail" in the real name field,
since that will match in the  case you really want to avoid matching!

Mike
(the sad owner of mike.shaver@gmail.com in bugzilla, unused but still muddling)
0
Mike
6/12/2009 1:32:26 PM
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
0
Gervase
6/12/2009 1:55:38 PM
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

0
Gervase
6/12/2009 1:56:33 PM
On Fri, Jun 12, 2009 at 9:55 AM, Gervase Markham<gerv@mozilla.org> wrote:
> 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.

I'd like it in a bookmarkable template; I routinely create templates
that have summaries and so forth in them, that I then tweak before
submitting.  I don't know why I wouldn't do that with aliases as well.
 If it throws an error, so be it -- it can throw an error if I don't
put a summary in too (or if I choose a pre-existing summary).

Mike
0
Mike
6/12/2009 2:08:23 PM
On 12/06/09 14:07, Mike Shaver wrote:
> It will split the conversation for people using the mailing lists, if
> nothing else.  (I saw this in dev-quality, others seem to have seen it
> in other groups; I doubt we'll all see each other's replies.)

You are quite right. Drat.

>> Perhaps we need a mozilla.dev.announce.)
>
> I think we generally use .planning for that, these days.

OK, as long as that sort of use is approved, and we won't get people 
saying "it's not planning, stop spamming me".

> Thanks for taking this on!

And thanks for your detailed comments. Some clarificatory questions:

> Let me first say that I don't want any changes to the bugzilla UI.
> Firefox's needs are clearly sufficiently different from the rest of
> the world's that accommodating them is painful and invasive.  I just
> want the tools to build a UI and workflow that suits us.

Is that "I don't want" as in "it's fine as it is", or "I don't want" as 
in "I'm not proposing that we demand, but if they happen, so much the 
better"? (I assume the latter.)

> - server-side hooks for basically every action, so that f.e. I could
> write something that did component watching the way I want without
> having to even discuss it with upstream, let alone make it
> sufficiently general to be accepted.

This seems a bit vague. Did you mean something specific by "action"?

> - ability to do historical queries on bug attributes ("what were all
> the bugs with blocking-firefox3.5+ on Friday?") so that people can
> stop scraping daily queries or trying to figure out the charting
> system

I've looked at this in the past, and thought that it's incredibly 
complicated. But I'll add it to the list nevertheless.

If the charting system sucked less, would that be a reasonable substitute?

> - no mandatory fields, all fields should be able to be multi-valued

Presumably not _all_ fields? (Summary, alias, product...)

> (this would let us solve the resolved-vs-fixed-keyword problem, as
> well as "vista and win7 but not win XP", and would let us have bugs in
> multiple components, multiple assignees for bugs, etc. -- we can argue
> about whether we want to permit that in different parts of our product
> as a matter of policy, but the mechanism should be there)

Would some sort of bug-forking-and-association help here? So you clone 
the bug, the clone(s) and the original are automatically associated 
(e.g. as tabs along the top) and each clone is labelled in a way which 
distinguishes it from the others (e.g. "1.9.1 branch bug")?

> - intelligent caching of API and web-UI results, based on modification
> time for bugs; "generate on change" via the server side hooks would be
> a DIY option, certainly

You mean so you don't regenerate a bug's page if it hasn't changed? Some 
things still vary based on the group you are in (e.g. private comments). 
A bug is not viewed the same way by everyone :-| We'd need to measure 
before optimisation. Is speed the underlying concern here?

> configuration changes:
>
> - at least 80% fewer components, and many fewer products.  We have 8
> different DOM components, but nowhere obvious to put postMessage; 7
> Java-related components; 12 different layout components; SQL (not
> supported anywhere, and not related to our own sqlite use or APIs); 9
> different widget components, etc. -- and that's just Core.  Mostly
> these subdivisons seem to be used as ways to narrow queries or get
> bugmail people want, all of which I think would be done better through
> attribute-based notifications/queries instead of something between the
> reporter and the bug.  (I routinely have to take an entire minute just
> to figure out what product+component I want to file a bug, and I
> usually already know what code it's in!)

We just did a big reorganization ;-) OK, so I guess the counter-argument 
is that at the moment it's split up by areas of responsibility, and 
perhaps a better way forward is not to make you choose at bug-filing 
time where it lives. Is the underlying problem bug filing complexity, or 
something else as well?

Gerv
0
Gervase
6/12/2009 2:10:39 PM
On 12/06/09 13:39, Andreas Nilsson wrote:
> One of the things I like with the GNOME bugzilla is that the attachment
> column makes better use of the screen width.
> Mozilla: http://www.andreasn.se/diverse/temp/bugzilla-mozilla.png
> GNOME: http://www.andreasn.se/diverse/temp/bugzilla-gnome.png

Hmm. I'm not sure it's any easier to read and understand, though. Are 
you concerned about the vertical space the attachments section takes up? 
Would that be better solved with an option to hide obsolete attachments 
by default?

Gerv
0
Gervase
6/12/2009 2:12:55 PM
On 06/12/2009 04:12 PM, Gervase Markham wrote:
> On 12/06/09 13:39, Andreas Nilsson wrote:
>> One of the things I like with the GNOME bugzilla is that the attachment
>> column makes better use of the screen width.
>> Mozilla: http://www.andreasn.se/diverse/temp/bugzilla-mozilla.png
>> GNOME: http://www.andreasn.se/diverse/temp/bugzilla-gnome.png
>
> Hmm. I'm not sure it's any easier to read and understand, though. Are 
> you concerned about the vertical space the attachments section takes 
> up? Would that be better solved with an option to hide obsolete 
> attachments by default?
Not really concerned, but I found myself doing less scrolling in the 
GNOME bugzilla and thought it was nice. So it's on the 
would-be-neat-list, rather than the must-be-changed-to-be-usable-list. 
Hiding obsolete attachments sounds like a good idea as well.
- Andreas
0
Andreas
6/12/2009 2:21:00 PM
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.
0
Andrew
6/12/2009 2:22:43 PM
On Fri, Jun 12, 2009 at 10:10 AM, Gervase Markham<gerv@mozilla.org> wrote:
>> Let me first say that I don't want any changes to the bugzilla UI.
>> Firefox's needs are clearly sufficiently different from the rest of
>> the world's that accommodating them is painful and invasive. =A0I just
>> want the tools to build a UI and workflow that suits us.
>
> Is that "I don't want" as in "it's fine as it is", or "I don't want" as i=
n
> "I'm not proposing that we demand, but if they happen, so much the better=
"?
> (I assume the latter.)

The latter; I want a lot of b.m.o UI changes, but I don't want to have
to worry whether they're OK bugzilla-upstream changes.

>> - server-side hooks for basically every action, so that f.e. I could
>> write something that did component watching the way I want without
>> having to even discuss it with upstream, let alone make it
>> sufficiently general to be accepted.
>
> This seems a bit vague. Did you mean something specific by "action"?

Any time that a change is made to the underlying database -- user
profile modifications, bug changes, flag creation, etc.

>> - ability to do historical queries on bug attributes ("what were all
>> the bugs with blocking-firefox3.5+ on Friday?") so that people can
>> stop scraping daily queries or trying to figure out the charting
>> system
>
> I've looked at this in the past, and thought that it's incredibly
> complicated. But I'll add it to the list nevertheless.
>
> If the charting system sucked less, would that be a reasonable substitute=
?

Not unless the charting system sucked less in a way that let it do
historical queries, and produced useful API output.

>> - no mandatory fields, all fields should be able to be multi-valued
>
> Presumably not _all_ fields? (Summary, alias, product...)

Yes, all fields.  I may want duping a bug to add its previous summary
to the dup-target, for improved search.  I may well want to have two
aliases, and we have a _lot_ of bugs that are relevant to multiple
products, especially tracking and meta bugs.

Just give me the mechanism, worry about the policy later.

(Another item: improved search, both in criteria and in result output.
 Many heavy bugzilla users, myself included, use gmail search instead
of bugzilla to find things, because it's easily narrowed to bugs I've
seen, and because it does a better job -- even though it has no
knowledge of bugzilla metadata!)

>> (this would let us solve the resolved-vs-fixed-keyword problem, as
>> well as "vista and win7 but not win XP", and would let us have bugs in
>> multiple components, multiple assignees for bugs, etc. -- we can argue
>> about whether we want to permit that in different parts of our product
>> as a matter of policy, but the mechanism should be there)
>
> Would some sort of bug-forking-and-association help here? So you clone th=
e
> bug, the clone(s) and the original are automatically associated (e.g. as
> tabs along the top) and each clone is labelled in a way which distinguish=
es
> it from the others (e.g. "1.9.1 branch bug")?

No, because I don't want to have to update two bugs, or wonder which
one is "real" if they differ.  And I don't want to have to manually
scan the bugs to see _how_ the different tines differ, if I need
multivalue on something.

I really do want multivalued everything.  We can denormalize for
search efficiency if we need to later, but treating all our bug
attributes uniformly will make a lot of other things simpler too.

> You mean so you don't regenerate a bug's page if it hasn't changed? Some
> things still vary based on the group you are in (e.g. private comments). =
A
> bug is not viewed the same way by everyone :-| We'd need to measure befor=
e
> optimisation. Is speed the underlying concern here?

You can cache different versions based on relevant groups; Vary is
analogous in HTTP, and this isn't a research problem in the
web-application space.  The vast majority of bugs have no group issues
at all.  Speed and other resource usage is very much the concern --
sending a 301 back instead of generating a pile of HTML is a win for
everyone, especially as API use becomes more common.

> We just did a big reorganization ;-) OK, so I guess the counter-argument =
is
> that at the moment it's split up by areas of responsibility, and perhaps =
a
> better way forward is not to make you choose at bug-filing time where it
> lives. Is the underlying problem bug filing complexity, or something else=
 as
> well?

Bug filing complexity, query complexity, choice paralysis, how quickly
it gets out of date, the costs the bugzilla imposes for _removing_
components, the grotesque effects on the UI.  I _know_ things about
the kind of bug it is, just let me specify it in a way that doesn't
make me read all the descriptions of the components.

Related: hierarchical components.  Let me pick "Page Behaviour" if I
know it's a content-side problem, and then we can narrow to
layout/DOM/script (or multiple, if it's a script<->DOM interaction!)
later.  I can "watch" Page Behaviour, or query on it, but the JS team
can do that for script stuff more narrowly if they only care about
that.

Mike
0
Mike
6/12/2009 2:29:23 PM
On 12/06/09 14:32, Mike Shaver wrote:
> Relatedly, people should be able to hide their accounts from
> auto-completion or partial matching.  That would let us get rid of the
> poorly-named noise from gmail watcher accounts.
>
> (Autocomplete of usernames might be best if it only matched against
> people who had ever been put in a cc: field by someone other than
> themselves, not counting cloning or duping.)

Would this be best implemented by an "active" field, which can be set by 
the user but is automatically set after N months of no activity? When 
it's set, the user gets sent a "you are now inactive" email, bugmail 
stops, they stop showing up in autocomplete, etc. etc.

> (the sad owner of mike.shaver@gmail.com in bugzilla, unused but still muddling)

You know you can change the email address associated with a particular 
account, right? Or disable it, at which point it _should_ stop showing 
up (although there may be a bug on that)?

Gerv

0
Gervase
6/12/2009 2:29:34 PM
On Fri, Jun 12, 2009 at 10:29 AM, Gervase Markham<gerv@mozilla.org> wrote:
> You know you can change the email address associated with a particular
> account, right? Or disable it, at which point it _should_ stop showing up
> (although there may be a bug on that)?

Yeah, I just did that -- I didn't have another email address to which
to point it.  I'd rather just delete the account, tbqh, but that
wasn't an option I saw even as an administrator.

Mike
0
Mike
6/12/2009 2:31:28 PM
Mike Shaver wrote:
> On Fri, Jun 12, 2009 at 7:35 AM, Gervase Markham<gerv@mozilla.org> wrote:
>> (I apologise if the reasonably wide crossposting irritates anyone.
> 
> It will split the conversation for people using the mailing lists

For what it's worth, the correct way to handle that on the newsgroup 
side (which is where Gerv was coming from) is to set both followup-to 
_and_ reply-to (the latter to the right mailing list)...

It's a bit of a pain, of course.

-Boris
0
Boris
6/12/2009 3:00:10 PM
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


0
John
6/12/2009 3:38:25 PM
On Fri, Jun 12, 2009 at 11:38 AM, John J.
Barton<johnjbarton@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
0
Mike
6/12/2009 3:52:33 PM
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.
0
Dave
6/12/2009 4:12:14 PM
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.
0
Daniel
6/12/2009 4:13:20 PM
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
0
John
6/12/2009 4:13:53 PM
Mike Shaver wrote:
> On Fri, Jun 12, 2009 at 11:38 AM, John J.
> Barton<johnjbarton@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.

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
0
John
6/12/2009 4:23:26 PM
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
0
Benjamin
6/12/2009 4:26:52 PM
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



On 6/12/09, John J. Barton <johnjbarton@johnjbarton.com> wrote:
> Mike Shaver wrote:
>> On Fri, Jun 12, 2009 at 11:38 AM, John J.
>> Barton<johnjbarton@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.
>
> 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
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

-- 
Sent from Gmail for mobile | mobile.google.com
0
Mike
6/12/2009 4:29:45 PM
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
0
Justin
6/12/2009 4:32:00 PM
On 6/12/09 6:07 AM, Mike Shaver wrote:
> (or invisible -- why do I care who the default
> CC: is? why would I ever change the QA contact?)

On that note, it would be useful to have a better way of watching bug in 
certain areas. Following fake QA Contacts is hacky, and breaks when 
people don't reset the field when moving bugs. A simple "Send me email 
for bugs in Component X" setting would be a direct replacement, there 
are probably more clever ways (Eg, I might want to see all newly filed 
bugs with "password" in the summary, no matter where they're filed).

Justin
0
Justin
6/12/2009 4:39:11 PM
Justin Dolske wrote:
> On that note, it would be useful to have a better way of watching bug in 
> certain areas. Following fake QA Contacts is hacky, and breaks when 
> people don't reset the field when moving bugs.

Though note that default is to reset; you have to go out of your way to 
not do that.  Or have js disabled, possibly...

But yes, component watching would be nice.

-Boris
0
Boris
6/12/2009 4:53:24 PM
On Jun 12, 2009, at 9:26 AM, Benjamin Smedberg 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.

Yes. Definitely. This is my #1 request, by far. Dealing with bugs on  
branches now is a pain and things get lost/missed. We need this,  
regardless of how hard it is.

-Sam
0
Samuel
6/12/2009 5:21:31 PM
On 12/06/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' - 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.

This is awesome!  I'm really glad you're doing this work and I probably 
have way too many suggestions so I'll start with one that's pretty easy 
and I think would make a big improvement for the way I use bugmail.

I tend to delete bugmail messages as they arrive so each new message is 
often too terse to understand what is happening.  I'd love to see the 
bug mail add some extra information to the message about the current 
state of the bug.  Even if this information was just added to the 
signature area it would be worthwhile.

Here's some info that I'd like to see, essentially this is the 
information I feel I need to understand a bug from a single message.

1. current status
2. number of attachments / patches
3. Product / Component / OS
4. reported by and creation date

There's possibly other stuff to do, but in plain text I want to keep it 
simple and I know some of this info is available in the bugmail headers 
already.  The info being available in the headers is why I'm assuming it 
would be easy to add to the signature line.

Thanks,
~ Bryan
0
Bryan
6/12/2009 5:45:46 PM
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
0
Jesse
6/12/2009 6:03:28 PM
Ted Mielczarek on 6/12/2009 9:26 AM, keyboarded a reply:
> I would like to see someone finish (or rewrite) the patch I attached to bug
> 386600 - JavaScript autocomplete for review request field. For bonus points,
> the same backend code should be used anywhere else that you currently enter
> someone's bugmail in the UI. I waste an awful lot of time guessing at
> people's bugmail.
> 
> -Ted

If this is what I think it is, great, We need it. When doing Triage for Tb 
I often want one of the MoMo staff added to the CC when the description 
includes a particular aspect of the product, i.e. UX.  It would be so much 
faster to have an auto-complete or drop-down list of those peoples bugmail 
addresses which I frequently need.  This is in part driven by no visibility 
of the default mailing lists that only show while committing a comment.

Here is an idea I think will help reduce the Dupe work load.  Currently on 
accessing Bugzilla there are some links for pre-defined queries such as Hot 
Bugs and Todays Bugs.  What I am thinking about is a query of "Bugs in the 
last X days".
If Joe saw the bug yesterday, it will not show in a 'Today' query, and I 
have gone on to generate a bug that was actually a dupe. Make it a spin box 
with a range of 2-7, with 2 the default. Set the query to sort by product 
then bug#. Bonus if We can narrow the query so Fx stuff not related to Tb 
is filtered out, for example.


-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
0
Ron
6/12/2009 7:42:54 PM
On 12.06.2009 17:52 Uhr, Mike Shaver wrote:
> On Fri, Jun 12, 2009 at 11:38 AM, John J.
> Barton<johnjbarton@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.

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
0
Axel
6/12/2009 8:52:19 PM
Speaking of email notifications, I'd like to see:

Bug 97956 - Give summary and URL of bugs added or removed from 
dependencies in bugmail (notification mail)

Bug 125888 - Give summary/URL of bugs marked as duplicates

Steffen
0
Steffen
6/12/2009 8:58:20 PM
Dave Townsend <dtownsend@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
0
Blake
6/12/2009 9:03:38 PM
Justin Dolske <dolske@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
0
Blake
6/12/2009 9:11:10 PM
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.
0
Peter
6/12/2009 9:49:36 PM
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
0
Benjamin
6/12/2009 10:13:42 PM
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.


On Jun 12, 2009, at 11:03 AM, Jesse Ruderman wrote:

> 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
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

0
Alex
6/12/2009 10:59:43 PM
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.
0
Daniel
6/12/2009 11:31:20 PM
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
0
Daniel
6/12/2009 11:39:05 PM
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
0
Max
6/13/2009 12:09:29 AM
On Jun 12, 9:26=A0am, 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
0
Max
6/13/2009 12:14:45 AM
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
0
Samuel
6/13/2009 12:21:23 AM
On Jun 12, 3:59=A0pm, Alex Faaborg <faab...@mozilla.com> wrote:
> For the autocomplete, it would be even better if we searched against =A0
> 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 =A0started 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 / =A0
> 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 =A0
> 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
0
Max
6/13/2009 12:21:28 AM
On Jun 12, 5:21=A0pm, Samuel Sidler <s...@mozilla.com> wrote:
> "Fixed In" isn't even close to what we want, unfortunately. This has =A0
> been hashed out over and over, so I won't go into detail again, but we =
=A0
> basically need to know the status of bugs across branches, especially =A0
> status/resolution. Right now we do that with a mix of keywords and =A0
> 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
0
Max
6/13/2009 12:25:31 AM
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 usef=
ul.

On Jun 12, 12:26=A0pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> 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-filer=
s
> 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 ma=
kes
> 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

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
0
GPHemsley
6/13/2009 3:23:50 AM
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
0
John
6/13/2009 3:38:01 AM
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
0
Benjamin
6/13/2009 3:39:36 AM
GPHemsley <gphemsley@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
0
Zack
6/13/2009 3:43:45 AM
On Jun 12, 11:39=A0pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> 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 shou=
ld
> 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 h=
ave
> 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 bu=
g
> 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 som=
e
> 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 th=
ink
> the field somehow affects our decision-making.
>
> --BDS

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
0
GPHemsley
6/13/2009 3:52:20 AM
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.
0
David
6/13/2009 5:46:51 AM
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
0
ISO
6/13/2009 11:18:41 AM
2009/6/13 Fr=E9d=E9ric Buclin <LpSolit@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
0
Mike
6/13/2009 12:12:40 PM
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
0
ISO
6/13/2009 12:16:07 PM
2009/6/13 Fr=E9d=E9ric Buclin <LpSolit@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; thi=
s
> 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
0
Mike
6/13/2009 12:17:00 PM
2009/6/13 Fr=E9d=E9ric Buclin <LpSolit@gmail.com>:
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D449161

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

Mike
0
Mike
6/13/2009 12:22:21 PM
Le 13. 06. 09 14:22, Mike Shaver a �crit :
> 2009/6/13 Fr�d�ric Buclin<LpSolit@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).
0
ISO
6/13/2009 12:29:08 PM
2009/6/13 Fr=E9d=E9ric Buclin <LpSolit@gmail.com>:
> Le 13. 06. 09 14:22, Mike Shaver a =E9crit :
>>
>> 2009/6/13 Fr=E9d=E9ric Buclin<LpSolit@gmail.com>:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=3D449161
>>
>> 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 versio=
n
>> 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
0
Mike
6/13/2009 12:36:08 PM
On Fri, Jun 12, 2009 at 11:23 PM, GPHemsley<gphemsley@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
0
Mike
6/13/2009 12:39:37 PM
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 bugzilla@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
0
Robert
6/13/2009 1:04:06 PM
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
0
ISO
6/13/2009 1:25:29 PM
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
0
ISO
6/13/2009 1:33:31 PM
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.
0
Joshua
6/13/2009 1:58:52 PM
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 <LpSolit@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-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>   
0
chris
6/13/2009 2:04:46 PM
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.
0
Peter
6/13/2009 3:00:33 PM
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.
0
Peter
6/13/2009 3:06:17 PM
Mike Shaver wrote:
> On Fri, Jun 12, 2009 at 11:23 PM, GPHemsley<gphemsley@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
0
John
6/13/2009 3:30:41 PM
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.

Phil

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

0
Philip
6/13/2009 5:18:27 PM
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>

-- 
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.
0
David
6/13/2009 6:29:57 PM
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.
0
Joshua
6/13/2009 7:15:54 PM
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.
0
Kevin
6/13/2009 10:56:48 PM
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.
> 
> 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.

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.

-- 
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.
0
David
6/13/2009 11:55:04 PM
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
0
ISO
6/14/2009 12:19:32 AM
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.

On Sat, Jun 13, 2009 at 19:55, David E. Ross<nobody@nowhere.not> wrote:
> 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.
>>
>> 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.
>
> 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. =A0Because 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). =A0The current Mozilla-wide
> database of bug reports allows these situations to be handled by merely
> changing the product. =A0Separating 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.
>
> --
> 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. =A0You can access Mozdev much
> more quickly than you can Mozilla Add-Ons.
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
0
Kevin
6/14/2009 12:33:35 AM
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!
0
Rich
6/14/2009 3:32:54 AM
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.

Phil

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

0
Philip
6/14/2009 5:01:19 AM
On 12/06/09 7: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.

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.
0
Chris
6/14/2009 5:48:36 AM
On 13/6/09 4:32 AM, Justin Dolske 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.

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
0
Robert
6/14/2009 5:48:46 AM
This may be beyond the scope of what's actually possible, but I think it 
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
0
Robert
6/14/2009 6:01:43 AM
On 14/06/09 15:48, Robert O'Callahan wrote:
> 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
0
Bradley
6/14/2009 7:15:10 AM
On Sat, Jun 13, 2009 at 10:15 PM, Joshua Cranmer<Pidgeot18@verizon.net> wrote:
> 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).
0
timeless
6/14/2009 9:07:40 AM
Without unified auth/credentials, you're causing pain.

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.
0
timeless
6/14/2009 9:12:27 AM
On Sun, Jun 14, 2009 at 8:48 AM, Chris Ilias<nmo@ilias.ca> wrote:
> * 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.
0
timeless
6/14/2009 9:21:54 AM
On 14/06/09 5:21 AM, timeless wrote:
> 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!
0
Chris
6/14/2009 2:18:18 PM
On 6/13/09 8:00 AM, Peter Weilbacher wrote:

> 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
0
Benjamin
6/14/2009 7:00:49 PM
On 6/13/09 10:18 AM, Philip Chee wrote:

>> 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
0
Benjamin
6/14/2009 7:06:30 PM
On 6/14/2009 12:00 PM, Benjamin Smedberg wrote:
> On 6/13/09 8:00 AM, Peter Weilbacher wrote:
> 
>> 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

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.

-- 
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.
0
David
6/14/2009 8:45:07 PM
On Jun 14, 3:06=A0pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:

> * 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 an=
d
> 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 =3D
Mac OS X, and I regularly find by other means bugs affecting only Mac
OS X that have OS =3D Windows or OS =3D 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.
0
Smokey
6/14/2009 9:09:17 PM
On Jun 13, 10:48=A0pm, Chris Ilias <n...@ilias.ca> wrote:
> * 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=3D11368

> * The ability to subscribe to keywords.

  That's this bug:

  https://bugzilla.mozilla.org/show_bug.cgi?id=3D278455

> 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
0
Max
6/14/2009 9:55:16 PM
On Jun 13, 11:01=A0pm, 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, 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
0
Max
6/14/2009 9:58:43 PM
David E. Ross wrote:
> 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
0
Boris
6/14/2009 10:05:01 PM
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.

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.
0
Robert
6/14/2009 10:24:12 PM
On Sat, Jun 13, 2009 at 7:55 PM, David E. Ross<nobody@nowhere.not> wrote:
> 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.
>
> 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.

Or in sqlite or cairo or the Windows SDK or CoreGraphics or ...

> =A0Because 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.

> =A0The 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
0
Mike
6/15/2009 12:12:17 AM
On Sun, Jun 14, 2009 at 8:12 PM, Mike Shaver<mike.shaver@gmail.com> wrote:
> On Sat, Jun 13, 2009 at 7:55 PM, David E. Ross<nobody@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.
0
Mike
6/15/2009 12:17:30 AM
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.

Pfc. Roy Mercon
Public Affairs Specialist
Vermont Army National Guard
Phone: (802) 473-0083

On Jun 14, 2009, at 20:17, Mike Shaver <mike.shaver@gmail.com> wrote:

> On Sun, Jun 14, 2009 at 8:12 PM, Mike Shaver<mike.shaver@gmail.com>  
> wrote:
>> On Sat, Jun 13, 2009 at 7:55 PM, David E. Ross<nobody@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.
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
0
Roy
6/15/2009 12:25:30 AM
On 6/14/09 2:09 PM, Smokey Ardisson wrote:

> 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
0
Benjamin
6/15/2009 12:42:37 AM
Benjamin Smedberg wrote:
> 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. :/

-- 
Rich        (Pull thorn from address to e-mail me.)
SeaMonkey - Surfing the net has never been so suite!
0
Rich
6/15/2009 2:02:09 AM
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?

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).

-- 
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.
0
David
6/15/2009 2:54:38 AM
On 13.06.2009 1:39 Uhr, Daniel Veditz wrote:
> 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
0
Axel
6/15/2009 8:50:34 AM
On 15/06/09 12:54, David E. Ross wrote:

> 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
0
Bradley
6/15/2009 8:55:15 AM
On 15/6/09 9:58 AM, Max wrote:
> 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
0
Robert
6/15/2009 8:56:42 AM
On 12.06.2009 15:55 Uhr, 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?
>

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
0
Axel
6/15/2009 9:05:15 AM
On 06/15/2009 05:54 AM, David E. Ross:
> 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: startcom@startcom.org
Blog:  	https://blog.startcom.org

0
Eddy
6/15/2009 9:12:42 AM
First suggestion:
- 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
0
Archaeopteryx
6/15/2009 9:33:07 AM
On 12/06/09 17:13, Daniel Veditz wrote:
> 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

0
Gervase
6/15/2009 9:42:34 AM
On 13/06/09 04:38, John J. Barton wrote:
> 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
0
Gervase
6/15/2009 9:53:01 AM
On 12/06/09 22:03, Blake Kaplan wrote:
> 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

0
Gervase
6/15/2009 9:54:39 AM
On 12/06/09 17: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.

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
0
Gervase
6/15/2009 9:59:04 AM
On 13/06/09 13:36, Mike Shaver wrote:
> 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
0
Gervase
6/15/2009 10:10:35 AM
On 13/06/09 04:43, Zack Weinberg wrote:
> 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

0
Gervase
6/15/2009 10:13:09 AM
On 13/06/09 13:39, Mike Shaver wrote:
> 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

0
Gervase
6/15/2009 10:17:16 AM
On 13/06/09 06:46, 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.

That is why it is proposed that the replacement would be keywords, for 
which specific values are defined.

Gerv
0
Gervase
6/15/2009 10:18:32 AM
On 13/06/09 23:56, Kevin Brosnan wrote:
> 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

0
Gervase
6/15/2009 10:19:20 AM
On 15/06/09 01:25, Roy Mercon wrote:
> 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-planning@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-planning

which takes you where you need to go to unsubscribe.

Gerv

0
Gervase
6/15/2009 10:26:24 AM
On 12/06/09 15:29, Mike Shaver wrote:
> No, because I don't want to have to update two bugs, or wonder which
> one is "real" if they differ.  And I don't want to have to manually
> scan the bugs to see _how_ the different tines differ, if I need
> multivalue on something.

But if every field were multi-valued, wouldn't that make the UI a lot 
more complex?

> Related: hierarchical components.  Let me pick "Page Behaviour" if I
> know it's a content-side problem, and then we can narrow to
> layout/DOM/script (or multiple, if it's a script<->DOM interaction!)
> later.  I can "watch" Page Behaviour, or query on it, but the JS team
> can do that for script stuff more narrowly if they only care about
> that.

Again, how might the UI (for the bug and for search) work for that?

Gerv

0
Gervase
6/15/2009 10:43:38 AM
On 12/06/09 18:45, Bryan Clark wrote:
> I tend to delete bugmail messages as they arrive so each new message is
> often too terse to understand what is happening. I'd love to see the bug
> mail add some extra information to the message about the current state
> of the bug. Even if this information was just added to the signature
> area it would be worthwhile.

Install the "Bugmail" Thunderbird extension, for a start :-) It's great. 
It gives you up-to-date Status/Resolution, Product/Component and assignee.

> Here's some info that I'd like to see, essentially this is the
> information I feel I need to understand a bug from a single message.
>
> 1. current status
> 2. number of attachments / patches
> 3. Product / Component / OS
> 4. reported by and creation date

If you need _all_ that, you are better off loading the bug. After all, 
some of that data may have changed since the mail was sent.

Gerv
0
Gervase
6/15/2009 10:48:00 AM
On 15/06/09 10:33, Archaeopteryx wrote:
> - 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

0
Gervase
6/15/2009 11:01:44 AM
On 14/06/09 23:24, Robert Kaiser wrote:
> 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
0
Gervase
6/15/2009 11:05:09 AM
On 15/06/09 18:56, Robert O'Callahan wrote:
> Ping times between here and California are around 200ms (round trip).

Hey, somewhere that's further than me! ;)

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

Its possible that there's some low hanging fruit - I don't think 
anyone's done profiling of Bugzilla for a while.

I've just filed a perf issue that would affect bugs with lots of 
comments (eg bug 915 which takes ~20 seconds to load) - 
https://bugzilla.mozilla.org/show_bug.cgi?id=498309 and there are 
probably a few more.

Bradley
0
Bradley
6/15/2009 11:25:29 AM
On 15/06/2009 12:01, Gervase Markham wrote:
> On 15/06/09 10:33, Archaeopteryx wrote:
>> - 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?

The "tagging" that exists in bugzilla (though has to be turned on in 
your user prefs to be visible) is sort of tagging and sort of useful. 
Unfortunately it suffers from terrible UI that makes it very frustrating 
to work with.
0
Dave
6/15/2009 11:32:09 AM
Gervase Markham wrote:
> On 14/06/09 23:24, Robert Kaiser wrote:
>> 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 ;-)

"me" coming along is the wrong thing to say as it most likely was the 
still-running Bugzilla process on the server, while I had "This document 
contains no data" on my screen and (wrongly) thought it stopped 
processing. Fun times.

Robert Kaiser
0
Robert
6/15/2009 11:52:12 AM
"Gervase Markham" <gerv@mozilla.org> wrote in message news:4A3621D0.4050303@mozilla.org...
> On 15/06/09 01:25, Roy Mercon wrote:
>> 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-planning@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-planning
> 
> which takes you where you need to go to unsubscribe.

Not always the case with all mailing lists, or how readable it is,
but these mailing lists have unsubscribe information in the email headers.
Much better to  use newsgroups than mailing lists.

List-Unsubscribe: <https://lists.mozilla.org/options/dev-planning>,
	<mailto:dev-planning-request@lists.mozilla.org?subject=unsubscribe>
 
0
David
6/15/2009 2:15:42 PM
On 14.06.2009 21:00, Benjamin Smedberg wrote:
> On 6/13/09 8:00 AM, Peter Weilbacher wrote:
>
>> 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?

Yes, if there are many of them the UI field won't be able to display all of
them and one needs to scroll. But additionally, even if that field would be
made larger or even multi-line, then it would be difficult to find what one
is looking at. In the current UI, with the flags well separated into dropdowns,
one knows where to look for versions, blocking and other flags, keywords,
priorities etc.
If you put all that into the keywords field, then you will have an awful mess.
because you have to look through the whole field within which each flag will
change position with every bug.

    Peter.
0
Peter
6/15/2009 2:22:16 PM
Le 15. 06. 09 13:32, Dave Townsend a écrit :
> The "tagging" that exists in bugzilla (though has to be turned on in
> your user prefs to be visible) is sort of tagging and sort of useful.
> Unfortunately it suffers from terrible UI that makes it very frustrating
> to work with.

We know that. The UI to tag bugs will be improved in Bugzilla 3.6/4.0, 
see bug 372023.

LpSolit
0
UTF
6/15/2009 2:45:03 PM
On 6/15/2009 1:55 AM, Bradley Baetz wrote [in part]:
> On 15/06/09 12:54, I previously wrote [also in part]:
>> 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.
> 

I'm on a dial-up connection, as are 10%-20% of U.S. Internet users.

-- 
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.
0
David
6/15/2009 2:47:30 PM
On 6/15/09 2:59 AM, Gervase Markham wrote:

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

I am more concerned about the search UI and the data at the top of each bug
than the bug-filing process. But I will avoid belaboring that point...

>> * 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.

Maybe. Right now it feels very strange to me: I want to mark a bug as
INVALID or WONTFIX or whatever, but that's not one of my options... then I
realize that I need to choose RESOLVED and then some other box will appear.
Perhaps that is specific to me.

--BDS


0
Benjamin
6/15/2009 3:56:04 PM
Gervase Markham wrote:
> On 13/06/09 04:38, John J. Barton wrote:
....
> 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?

How is it helpful to embed the web page address in markup linked to text 
on the page, when the address can always be typed into the location field?

If you build FF every day, then you don't need such a feature. Otherwise 
  you have to know quite a lot (eg what cryptic strings mean 'checkin', 
where the nightly builds are etc), look at the date, covert the date 
into the form used on the nightly build site, scroll through that site 
and ponder its wonders, then install the build. There are lots of 
barriers and ways to make mistakes, so you don't do this twice.

> 
>> 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 :-)

Exactly. Which is why I need install the build and run the test 
manually. Which currently too hard for anyone but specialists.

jjb
0
John
6/15/2009 4:10:20 PM
Gervase Markham <gerv@mozilla.org> wrote:
> On 13/06/09 04:38, John J. Barton wrote:
....
> > 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?

It's not always build X - the patch might get backed out.  Yes, in that
case the bug is REOPENED, but this is not always obvious in a bug with
a long discussion trail.

Also, having a direct link from the bug to the first build that should
contain the fix would make it much easier for reporters and other
interested parties to download that build and try it.

zw
0
Zack
6/15/2009 4:11:11 PM
On 6/12/09 7:22 AM, Andrew Sutherland wrote:

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

What asuth says.  There are a bunch of ways in which I think Bugzilla 
should evolve, but none of them are likely if we can't easily experiment 
in a decentralized fashion.

There are _lots_ of different kinds of users for b.m.o, even more for 
bugzilla itself, and an endless thread is guaranteed not to reach 
consensus, given the scale and diversity of the audience.

If bugzilla is more of an API end-point, then people who have complaints 
with the current tool (such as me) can reasonably be told: it's an API, 
show me what you mean, and then we can look at working software, 
consider what belongs upstream, what belongs in b.m.o, what belongs in 
satellite bugzilla instances, what belongs in different front-ends, what 
belongs in jetpacks, etc.

JSON or XML blobs, XML-RPC or REST APIs, RSS/Atom feeds for change 
notifications, etc; ignore security-sensitive bugs for now.  Let a 
thousand flowers bloom!

--david
0
David
6/15/2009 5:39:16 PM
On 6/12/09 3:59 PM, Alex Faaborg wrote:
> 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.
I also am an enthusiastic supporter of a Next Action field.  Would 
Bugzilla's existing custom field functionality be good enough to 
experiment with this on bmo today?
> 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
I think Jay Patel has been looking into something a bit similar to this 
as a separate project; I'm not sure whether that's really applicable 
here or not.  I bet he can be talked into chiming in, though...

Dan

0
Dan
6/15/2009 9:06:21 PM
Dan Mosedale wrote:
>> 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 
> I think Jay Patel has been looking into something a bit similar to 
> this as a separate project; I'm not sure whether that's really 
> applicable here or not.  I bet he can be talked into chiming in, 
> though...
>
> Dan 

I'm hoping to launch the CRM (aka mozillians.org) sometime in July, so 
we will definitely have a "community directory" where we can encourage 
all Bugzilla users to update their profile in the system so we can look 
folks up and communicate with them as needed outside of Bugzilla.

We can be proactive once the site is up to send out email invites to all 
Bugzilla accounts once we have imported the email list (if we want to do 
that)... or we can slowly build out profiles by reaching out to 
community members through other channels and groups.

I plan to do an alpha with a few select community groups including l10n 
(Seth B.) and campus reps (me)... but if there are other folks 
interested in trying out the site early and think their teams will be 
open to evaluating and testing out the site, let me know.

Thanks.
- Jay
0
Jay
6/15/2009 9:18:25 PM
On Jun 14, 3:24=A0pm, Robert Kaiser <ka...@kairo.at> wrote:
> I painfully learned today that mass-changes are quite slow (I did a
> status change and a comment post) right now in our Bugzilla,

  Hmmm, that actually shouldn't be the case. It's possible that there
are some customizations to bmo that are causing this.

  -Max
0
Max
6/15/2009 9:48:09 PM
On Jun 15, 2:42=A0am, Gervase Markham <g...@mozilla.org> wrote:
> I would _hope_ that the charts a particular person gets are reflective
> of the bugs that person can see,

  How could that be true? Charts record only the count of bugs they
found each day, not any details about the bug. If I could see a bug
one day and then not see it another day, it would still show up in the
charts, and Bugzilla would have no way of knowing how to restrict me
access to the numbers.

  -Max
0
Max
6/15/2009 9:52:57 PM
On 15/06/2009 22:52, Max wrote:
> On Jun 15, 2:42 am, Gervase Markham<g...@mozilla.org>  wrote:
>> I would _hope_ that the charts a particular person gets are reflective
>> of the bugs that person can see,
>
>    How could that be true? Charts record only the count of bugs they
> found each day, not any details about the bug. If I could see a bug
> one day and then not see it another day, it would still show up in the
> charts, and Bugzilla would have no way of knowing how to restrict me
> access to the numbers.

So presumably then charts only count public bugs?
0
Dave
6/15/2009 11:32:35 PM
Gervase Markham wrote:
>> 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?

Because currently that information isn't always in the bug, or isn't
obvious. Many developers are including links to the Hg changeset these
days -- kudos for that. But even when they are you still have to scan
the entire bug and hope that such a link was included. If there is no
such link you have to open the bug history and look for the resolution
change timestamp, hope the developer remembered to mark the bug fixed
reasonably close to the check-in, and then hunt backwards through the Hg
pushlog from that point hoping to find the bug number in a checkin comment.

Not sure how that could possibly be automated though. Especially not
across products and repos and different branch rules.

For similar reasons it would be nice to add the resolution timestamp to
the front of the bug, near the opened and modified times (blank if the
bug is not resolved or reopened, and the most recent resolution if the
bug was reopened and then re-resolved). Would also be nice to have that
available as a column in buglists.

I'm sure this is not useful to a broad spectrum of people, but it would
be very useful for branch triage. It would also be helpful in long bugs
trying to figure out how far into the comments to scroll looking for a
changeset link. One improvement that might be easily automated would be
to make the resolution timestamp a link to the comment made (if any)
when resolving the bug -- similar in function to the "Last comment"
link, except remaining useful if the bug sputters on about various
branch fix porting.

-Dan
0
Daniel
6/15/2009 11:33:22 PM
Daniel Veditz <dveditz@mozilla.com> wrote:
> 
> Not sure how [mapping bug fixes to builds] could possibly be automated
> though. Especially not across products and repos and different branch
> rules.

A start might be hg push hooks that notice bug numbers in the checkin
comment and automatically annotate the bug with the relevant changeset
link.  And then we could also have buildbot hooks that report the build
results to those bugs, giving links to the full logs.

Not sure how to get a link to the right nightly in there, though.

zw
0
Zack
6/16/2009 12:00:05 AM
Dave Townsend wrote:
> On 15/06/2009 22:52, Max wrote:
>> On Jun 15, 2:42 am, Gervase Markham<g...@mozilla.org>  wrote:
>>> I would _hope_ that the charts a particular person gets are reflective
>>> of the bugs that person can see,
>>
>>    How could that be true? Charts record only the count of bugs they
>> found each day, not any details about the bug. If I could see a bug
>> one day and then not see it another day, it would still show up in the
>> charts, and Bugzilla would have no way of knowing how to restrict me
>> access to the numbers.
> 
> So presumably then charts only count public bugs?

They most certainly are not restricted to public bugs. Many of my charts
are counts of security bugs where every single bug on a particular chart
is non-public.

The trick is no one but me can request my data sets, although they can
see the sets I created in the chart UI. It's suboptimal on both counts:
I'd like to be able to selectively share my charts the way I can share
my queries (private by default!), and people shouldn't have to deal with
a huge list of unselectable data sets.

-Dan Veditz
0
Daniel
6/16/2009 5:48:22 AM
Axel Hecht wrote:
> 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.

I've been experimenting with the built-in microsummaries. If you
bookmark a buglist you can change the title using the drop-down to one
that includes the count. DO NOT EDIT THIS TITLE. Even if it has a
useless title "Bug List (54)" if you edit it you break the microsummary.
What you must do instead is create a bunch of named queries, and _then_
the microsummary will be "myqueryname (54)" and be updated periodically.

If you created one for each locale and put it in a folder on your
bookmarks bar you could check the current bug counts at a glance, and
then load the query if you need the details. A bit of a pain to set up,
but I've been playing with it the last couple of weeks to help with
branch triage and I think it will end up being useful.

Another gotcha: do NOT use a '+' in the name of your query. It works
fine as a query, but the microsummary for it will be broken. (you can
get around that by editing the sqlite database to replace the '+' with
"%2B" in the right field of the places database, but I don't recommend it.)

-Dan
0
Daniel
6/16/2009 5:58:07 AM
Gervase Markham wrote:
> On 12/06/09 22:03, Blake Kaplan wrote:
>> 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?

That is *one* use for the version field. The other use is to indicate
"this problem first appeared in this version". Without reading the bug
you can't really tell which one is meant. (and of course a single
version field is useless in the first sense if a particular bug happens
on TWO branches, but not others)
0
Daniel
6/16/2009 6:01:46 AM
On Jun 15, 2:06=A0pm, Dan Mosedale <dmo...@gmail.com> wrote:
> I also am an enthusiastic supporter of a Next Action field. =A0Would
> Bugzilla's existing custom field functionality be good enough to
> experiment with this on bmo today?

  Yeah. Not for Next Action Assignee, though.

  -Max
0
Max
6/16/2009 6:55:14 AM
On Jun 15, 4:32=A0pm, Dave Townsend <dtowns...@mozilla.com> wrote:
> > =A0 =A0How could that be true? Charts record only the count of bugs the=
y
> > found each day, not any details about the bug. If I could see a bug
> > one day and then not see it another day, it would still show up in the
> > charts, and Bugzilla would have no way of knowing how to restrict me
> > access to the numbers.
>
> So presumably then charts only count public bugs?

  Not exactly. The point I was making is that somebody could create a
chart that includes private bugs, share it with others who can't see
those private bugs, and expose information about private bugs.

  However, public charts should be visible without a login. Whether
they are or not, I have no idea, because I have always avoided using
New Charts.

  -Max
0
Max
6/16/2009 6:56:34 AM
On Jun 15, 10:58=A0pm, Daniel Veditz <dved...@mozilla.com> wrote:
> Another gotcha: do NOT use a '+' in the name of your query. It works
> fine as a query, but the microsummary for it will be broken.

  This probably indicates a lack of filtering on our (Bugzilla's)
side. How should we be filtering microsummary output?

  -Max
0
Max
6/16/2009 6:58:00 AM
On Jun 15, 4:33=A0pm, Daniel Veditz <dved...@mozilla.com> wrote:
> Not sure how that could possibly be automated though. Especially not
> across products and repos and different branch rules.

  It's not that hard. If you mention the bug number in the changeset
description, we can show a list of links to the changesets, in
Bugzilla, by parsing the logs on any branch under a certain directory.

  -Max
0
Max
6/16/2009 7:19:33 AM
Hi Gerv,

Although I'm not a developer, but actively following the development.

So, for me it is really helpful to have more verbose RSS feeds on bug 
searches. It's quite the same needs as requested for bugmail (comments, 
field changes).

/dennis

On 06/12/2009 02:35 PM, 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,
> 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

0
Dennis
6/16/2009 7:53:58 AM
Zack Weinberg wrote:
> Daniel Veditz <dveditz@mozilla.com> wrote:
>> Not sure how [mapping bug fixes to builds] could possibly be automated
>> though. Especially not across products and repos and different branch
>> rules.
> 
> A start might be hg push hooks that notice bug numbers in the checkin
> comment and automatically annotate the bug with the relevant changeset
> link.  And then we could also have buildbot hooks that report the build
> results to those bugs, giving links to the full logs.

We would have to be far more formal in the structure of our checkin
comments. "bug XXX: fix regression from bug YYY" shouldn't mark both
bugs fixed. "Backed out fix for bug xxx" certainly shouldn't mark a bug
fixed.
0
Daniel
6/16/2009 8:08:03 AM
Zack Weinberg wrote:
> Daniel Veditz <dveditz@mozilla.com> wrote:
>> Not sure how [mapping bug fixes to builds] could possibly be automated
>> though. Especially not across products and repos and different branch
>> rules.
> 
> A start might be hg push hooks that notice bug numbers in the checkin
> comment and automatically annotate the bug with the relevant changeset
> link.  And then we could also have buildbot hooks that report the build
> results to those bugs, giving links to the full logs.

We would have to be far more formal in the structure of our checkin
comments. "bug XXX: fix regression from bug YYY" shouldn't mark both
bugs fixed. "Backed out fix for bug xxx" certainly shouldn't mark a bug
fixed.
0
Daniel
6/16/2009 8:08:03 AM
Max wrote:
> On Jun 15, 10:58 pm, Daniel Veditz <dved...@mozilla.com> wrote:
>> Another gotcha: do NOT use a '+' in the name of your query. It works
>> fine as a query, but the microsummary for it will be broken.
> 
>   This probably indicates a lack of filtering on our (Bugzilla's)
> side. How should we be filtering microsummary output?

I believe the fault is the <link rel=microsummary> href. It should be
escaped in the buglist source.
https://bugzilla.mozilla.org/show_bug.cgi?id=496192
0
Daniel
6/16/2009 8:12:55 AM
On 06/13/2009 03:12 PM, Mike Shaver wrote:
> 2009/6/13 Fr=E9d=E9ric Buclin<LpSolit@gmail.com>:
>> There is no cost if projects which don't need these fields ignore them=
=2E
>
> How can we hide them, from all bugzilla UI?  There is definitely
> complexity cost to having more fields in submission, query, and
> display.

I see this as site- and user-customizable bugpage view.
Kind of "show/hide/collapse fields/groups to me" where hide and collapse =

are different things.

Another approach - role-based views (could be tabbed)

But anyway, it is quite a big effort to implement.

/dennis

0
Dennis
6/16/2009 8:58:52 AM
On 16.06.2009 7:58 Uhr, Daniel Veditz wrote:
> Axel Hecht wrote:
>> 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.
>
> I've been experimenting with the built-in microsummaries. If you
> bookmark a buglist you can change the title using the drop-down to one
> that includes the count. DO NOT EDIT THIS TITLE. Even if it has a
> useless title "Bug List (54)" if you edit it you break the microsummary.
> What you must do instead is create a bunch of named queries, and _then_
> the microsummary will be "myqueryname (54)" and be updated periodically.
>
> If you created one for each locale and put it in a folder on your
> bookmarks bar you could check the current bug counts at a glance, and
> then load the query if you need the details. A bit of a pain to set up,
> but I've been playing with it the last couple of weeks to help with
> branch triage and I think it will end up being useful.
>
> Another gotcha: do NOT use a '+' in the name of your query. It works
> fine as a query, but the microsummary for it will be broken. (you can
> get around that by editing the sqlite database to replace the '+' with
> "%2B" in the right field of the places database, but I don't recommend it.)

That really sounds like you'd want a group-by RSS output?

That would impact on how often you hit the query, though, not sure if 
that's bad. microsummaries only load every half hour (unless you tweak 
the pref, or create a microsummary generator).

Axel
0
Axel
6/16/2009 9:16:59 AM
Daniel Veditz <dveditz@mozilla.com> wrote:

> Zack Weinberg wrote:
> > Daniel Veditz <dveditz@mozilla.com> wrote:
> >> Not sure how [mapping bug fixes to builds] could possibly be
> >> automated though. Especially not across products and repos and
> >> different branch rules.
> > 
> > A start might be hg push hooks that notice bug numbers in the
> > checkin comment and automatically annotate the bug with the
> > relevant changeset link.  And then we could also have buildbot
> > hooks that report the build results to those bugs, giving links to
> > the full logs.
> 
> We would have to be far more formal in the structure of our checkin
> comments. "bug XXX: fix regression from bug YYY" shouldn't mark both
> bugs fixed. "Backed out fix for bug xxx" certainly shouldn't mark a
> bug fixed.

I was imagining that the hook would just add a comment with the hg link
to every bug whose number it could find, leaving it to the human to
change states appropriately.

zw
0
Zack
6/16/2009 3:34:21 PM
Le 16. 06. 09 07:48, Daniel Veditz a écrit :
> The trick is no one but me can request my data sets, although they can
> see the sets I created in the chart UI. It's suboptimal on both counts:
> [...] and people shouldn't have to deal with
> a huge list of unselectable data sets.

That's bug 389396
0
UTF
6/16/2009 4:55:03 PM
And about 15:35 12 Jun 09 it was written from Gervase Markham to All:

 GM> Please say what the change you are requesting is, and why making it
 GM> would improve your life.

A text/plain response with bug title for any given bug number would be nice.

I just now realized how useful can be a MediaWiki extension that provides
title="..." for the any such hyperlinks that lead to bugzilla bugs.

 GM> References to previous discussions and bug numbers would help.

There is none; such an idea just strikes out of nothing previous.


With best Fidonet 2.0 regards,
Mithgol the Webmaster.

... 114. I will never accept a challenge from the hero.
0
Mithgol
6/16/2009 5:23:21 PM
Max wrote:
> On Jun 15, 4:33 pm, Daniel Veditz <dved...@mozilla.com> wrote:
>   
>> Not sure how that could possibly be automated though. Especially not
>> across products and repos and different branch rules.
>>     
>
>   It's not that hard. If you mention the bug number in the changeset
> description, we can show a list of links to the changesets, in
> Bugzilla, by parsing the logs on any branch under a certain directory.
>
>   -Max
> \

It might be worth looking at all the ways we try and get bugzilla to 
interact with other systems in hacky ways

bugzilla -> version control systems and change sets
             ->  soccoro crash-reporting stack signatures and topcrash 
reports

It would be a lot cleaner of we had dedicated fields that could link up 
information between these databases, instead of parsing a bunch of free 
form text in summaries, comments and status white boards.

-chofmann
0
chris
6/16/2009 5:59:52 PM
On 16/6/09 12:00 PM, Zack Weinberg wrote:
> Daniel Veditz<dveditz@mozilla.com>  wrote:
>> Not sure how [mapping bug fixes to builds] could possibly be automated
>> though. Especially not across products and repos and different branch
>> rules.
>
> A start might be hg push hooks that notice bug numbers in the checkin
> comment and automatically annotate the bug with the relevant changeset
> link.  And then we could also have buildbot hooks that report the build
> results to those bugs, giving links to the full logs.
>
> Not sure how to get a link to the right nightly in there, though.

That sounds like it could add quite a bit of noise to Bugzilla. Probably 
not my preferred solution.

Rob
0
Robert
6/16/2009 6:42:37 PM
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.
>  (...)
> 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 filed bugs for what came to my mind:

Bug 475021 - Visualize attachment types (show icons in attachment list). 
This would allow to easily identify images (often screen shots) as 
opposed to patches, archives, ...

Bug 498744 - Changing Product should show hint that Commit will show 
Component selection screen. Should be an easy win.

Bug 498750 - Direct replies to (reviewer) comments should be sent to the 
comment's author. This actually bugs me the most: If I reply to a 
reviewer's comment the reviewer isn't notified and I have to take 
measures to let him know. Every. Single. Time.

Greetings,

Jens

-- 
Jens Hatlak <http://jens.hatlak.de/>
SeaMonkey Trunk Tracker <http://smtt.blogspot.com/>
0
Jens
6/16/2009 10:16:24 PM
On Jun 16, 10:59=A0am, chris hofmann <chofm...@meer.net> wrote:
> It might be worth looking at all the ways we try and get bugzilla to
> interact with other systems in hacky ways
> [snip]

  Yeah, I agree. I think what might be best is to create open-
sourceable extensions that implement the interaction between Bugzilla
and the other systems you use, so that Mozilla could benefit from
them, but also other organizations with similar needs could re-use the
code. (Bugzilla supports extensions, for those who don't know.)

  -Max
0
Max
6/16/2009 10:41:42 PM
On 06/12/2009 04: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' - 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.

Start with the "Bug reporting etc." post from 05/24/2009 in
dev.apps.seamonkey.


0
NoOp
6/17/2009 2:35:37 AM
On Wed, Jun 17, 2009 at 12:30 AM, John J.
Barton<johnjbarton@johnjbarton.com> wrote:
> bugzilla notices things like "bug xxx" and "comment YYY". Couldn't it notice
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/abd967e2173b
> and place the changeset id in the database under the bug row? Couldn't the
> build system query the db by changeset and post back to the bug the test
> results and a link to the build?

Those URLs are very commonly used to indicate regression ranges, or
regressing changesets.  I don't think it's really feasible to
distinguish those cases without some more structure.

(I don't understand what you're saying about "query the db by
changeset", I admit -- every mention of an hg URL in a bug comment
should trigger a new build?)

Mike
0
Mike
6/17/2009 4:23:41 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' - that is to say, 
> asking people's opinion about which possible improvements would be most 
> useful.

bugzilla notices things like "bug xxx" and "comment YYY". Couldn't it 
notice
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/abd967e2173b
and place the changeset id in the database under the bug row? Couldn't 
the build system query the db by changeset and post back to the bug the 
test results and a link to the build?

(yes, this is a variation on another post I made somewhere in this 
thread, just suggesting the implementation is not so hard).

jjb
0
John
6/17/2009 4:30:39 AM
Mike Shaver wrote:
> On Wed, Jun 17, 2009 at 12:30 AM, John J.
> Barton<johnjbarton@johnjbarton.com> wrote:
>> bugzilla notices things like "bug xxx" and "comment YYY". Couldn't it notice
>> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/abd967e2173b
>> and place the changeset id in the database under the bug row? Couldn't the
>> build system query the db by changeset and post back to the bug the test
>> results and a link to the build?
> 
> Those URLs are very commonly used to indicate regression ranges, or
> regressing changesets.  I don't think it's really feasible to
> distinguish those cases without some more structure.

ok:
pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/abd967e2173b

> 
> (I don't understand what you're saying about "query the db by
> changeset", I admit -- every mention of an hg URL in a bug comment
> should trigger a new build?)

Query by changeset only means that a query on changeset=abd967e2173b 
gives the bug list containing bugs with:
pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/abd967e2173b
(actually not by text search I guess, but by db lookup)
Then the end of the build runs the query and posts the build results to 
any bugs that hit.

Now add an mq extension "qfixed <bug-number>".  It pushes the top of the 
queue and posts the changeset id to <bug-number>. You get two bug-mails, 
one with the changeset id post and one with the build result. In the 
meantime you are doing useful work like reading newsgroups rather than 
posting and building and checking and replying to people who want to 
know which build the fix landed in.

jjb
0
John
6/17/2009 4:51:42 AM
On 15/06/09 22:52, Max wrote:
>    How could that be true? Charts record only the count of bugs they
> found each day, not any details about the bug. If I could see a bug
> one day and then not see it another day, it would still show up in the
> charts, and Bugzilla would have no way of knowing how to restrict me
> access to the numbers.

You are quite right; "each series runs with the permissions of its 
creator" (collectstats.pl, line 555).

Gerv
0
Gervase
6/17/2009 11:05:17 AM
On 15/06/09 17:11, Zack Weinberg wrote:
> It's not always build X - the patch might get backed out.  Yes, in that
> case the bug is REOPENED, but this is not always obvious in a bug with
> a long discussion trail.

Presumably the reopening will be reflected by the fact that the bug says 
REOPEND at the top?

> Also, having a direct link from the bug to the first build that should
> contain the fix would make it much easier for reporters and other
> interested parties to download that build and try it.

To get this reliably right would involve much more integration between 
Bugzilla and Hg, and a change in working practices from developers (to 
associate checkins with specific bugs). This would be a fair amount of 
work; I'm not sure the gain is worth it. The advantages of the current 
looser coupling are, for example, there's not lots of admin when bugs 
are reopened, you can have one checkin reference multiple bugs or one 
bug reference multiple checkins, and so on.

Gerv
0
Gervase
6/17/2009 11:09:33 AM
On 16/06/09 00:33, Daniel Veditz wrote:
> Gervase Markham wrote:
>>> 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?
>
> Because currently that information isn't always in the bug, or isn't
> obvious. Many developers are including links to the Hg changeset these
> days -- kudos for that. But even when they are you still have to scan
> the entire bug and hope that such a link was included. If there is no
> such link you have to open the bug history and look for the resolution
> change timestamp, hope the developer remembered to mark the bug fixed
> reasonably close to the check-in, and then hunt backwards through the Hg
> pushlog from that point hoping to find the bug number in a checkin comment.

We should make it much easier to search Hg pushlogs. It would be 
entirely cool to have a link which appeared on every FIXED bug in the 
Firefox product which was "search pushlog for this bug number".

> Not sure how that could possibly be automated though. Especially not
> across products and repos and different branch rules.

Indeed.

> For similar reasons it would be nice to add the resolution timestamp to
> the front of the bug, near the opened and modified times (blank if the
> bug is not resolved or reopened, and the most recent resolution if the
> bug was reopened and then re-resolved). Would also be nice to have that
> available as a column in buglists.

Hmm. We'd need to start storing this as a separate field to have it 
added to buglists. I'll add this idea to the list.

Gerv

0
Gervase
6/17/2009 11:13:27 AM
On 14/06/09 08:15, Bradley Baetz wrote:
> On 14/06/09 15:48, Robert O'Callahan wrote:
>> 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.

It might be significant management overhead to maintain such lists. How 
many different ones would we need? One per component? Or product? Are 
the lists of people who accept reviews clearly defined already, or are 
the edges fuzzy?

Also, practically, to maintain them, you need fairly serious Bugzilla 
privileges - including the ability to add yourself to e.g. the security 
group. So we couldn't really hand them out far and wide...

> https://bugzilla.mozilla.org/userprefs.cgi?tab=flags (bmo customisation,
> not upstream) Again, per flag not per product.

I had no idea that this had been implemented.

Anyone know what the current mechanism is for announcing improvements to 
b.m.o.? Where should I be listening?

Gerv
0
Gervase
6/17/2009 11:18:43 AM
On 15/06/09 22:06, Dan Mosedale wrote:
> I think Jay Patel has been looking into something a bit similar to this
> as a separate project; I'm not sure whether that's really applicable
> here or not. I bet he can be talked into chiming in, though...

Indeed; this is also on the Foundation radar as something we want. And 
integrating it with Bugzilla/Chatzilla/Thunderbird is high on my list of 
wants. I think we should avoid turning Bugzilla itself into a social 
networking tool.

Gerv

0
Gervase
6/17/2009 11:20:14 AM
On 13/06/09 14:04, Robert Kaiser wrote:
> 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 bugzilla@foo.tld Bugzilla account, and
> it's very unhelpful to see "bugzilla: review+" on an attachment.

Added to the list.

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

That sounds a bit dangerous; you'd end up with attachments which said 
"review+: gerv", which I hadn't actually reviewed. It would be up to the 
honesty of the patch submitter to not submit something entirely different...

Gerv

0
Gervase
6/17/2009 11:28:11 AM
On 13/06/09 16:06, Peter Weilbacher wrote:
> 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.

Sounds like another request for autocomplete to me. Is that right? :-)
https://bugzilla.mozilla.org/show_bug.cgi?id=490923

Gerv

0
Gervase
6/17/2009 11:31:02 AM
On Wed, Jun 17, 2009 at 7:13 AM, Gervase Markham <gerv@mozilla.org> wrote:

> We should make it much easier to search Hg pushlogs. It would be entirely
> cool to have a link which appeared on every FIXED bug in the Firefox product
> which was "search pushlog for this bug number".


This is somewhat confounded by the lack of a standard way to indicate the
bug number in your commit message. For example, here's the regex we
currently use to linkify bug numbers in commit messages on hg.mozilla.org:
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/buglink.py#l10

-Ted
0
Ted
6/17/2009 11:35:19 AM
On 15/06/09 22:18, Jay Patel wrote:
> I'm hoping to launch the CRM (aka mozillians.org) sometime in July,

Just as a small thing, it would be good to try and set a trend for where 
to find this service for a particular project. So just as most people's 
planets are planet.<project>.org, would it be good to have this sort of 
service at people.<project>.org, i.e. people.mozilla.org?

Gerv
0
Gervase
6/17/2009 1:05:55 PM
On 16/06/09 08:53, Dennis Melentyev wrote:
> So, for me it is really helpful to have more verbose RSS feeds on bug
> searches. It's quite the same needs as requested for bugmail (comments,
> field changes).

Bug searches are about the status of bugs at a particular time; bug mail 
is about the changes made at a particular time. I can't quite see how 
you could combine the two without confusion. Can you give more details 
about what you mean (i.e. what happens now and what could happen in your 
ideal future)?

Thanks,

Gerv


0
Gervase
6/17/2009 1:07:04 PM
On 16/06/09 18:23, Mithgol the Webmaster wrote:
> A text/plain response with bug title for any given bug number would be nice.

Have you investigated the existing API?
http://www.bugzilla.org/docs/tip/en/html/api/

Gerv
0
Gervase
6/17/2009 1:10:25 PM
On 15/06/09 15:47, David E. Ross wrote:
> I'm on a dial-up connection, as are 10%-20% of U.S. Internet users.

But perhaps not 10-20% of Mozilla community members, or 10-20% of 
Bugzilla users generally.

If you don't mind me asking, are you on dial-up due to lack of other 
options in your area, or due to cost?

Gerv

0
Gervase
6/17/2009 1:16:48 PM
On 16/06/2009 00:33, Daniel Veditz wrote:
> Gervase Markham wrote:
>>> 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?
>
> Because currently that information isn't always in the bug, or isn't
> obvious. Many developers are including links to the Hg changeset these
> days -- kudos for that. But even when they are you still have to scan
> the entire bug and hope that such a link was included.

I did file a bug [1] and suggest that we have a field or something 
alongside each patch so that we could indicate the changeset of the 
patch that was checked in. IMHO this would provide a much clearer and 
quicker way of indicating the fix than including it in bug comments (and 
also would signify the patch had been checked in without the need to 
change its title).

As the one response on the bug says, patches committed to multiple 
repositories would be an issue, but having just thought about it, maybe 
making it multiple fields per patch something like the idea below would 
help.

- <patch name>
|
-- Changeset central/abcd1234 checked in [remove]
-- Changeset 1.9.1/abcd1235 check        [remove]
-- Changeset 1.9.1/abcd2345 backed out   [remove]
-- add another

Anyway, better stop designing here, just wanted to indicate I think 
there's ways around the single field issue and IMHO it would be much 
clearer than any current method. It doesn't have to be restricted to 
changesets, it could just be a link e.g. to bonsai (for cvs), or hg or 
even svn.

Standard8

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=455295

0
Mark
6/17/2009 1:29:23 PM
On 17/06/09 12:35, Ted Mielczarek wrote:
> This is somewhat confounded by the lack of a standard way to indicate the
> bug number in your commit message. For example, here's the regex we
> currently use to linkify bug numbers in commit messages on hg.mozilla.org:
> http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/buglink.py#l10

Maybe I'm just an old Perl geek, but that regexp looks very simple and 
positively readable to me :-)

Is there a search for the pushlog at the moment?

Gerv

0
Gervase
6/17/2009 1:43:43 PM
Hi David,

On 13/06/09 19:29, David E. Ross wrote:
> First attention should be given to bug reports against Bugzilla in
> bugzilla.mozilla.org, including RFE bugs.

There are a rather large number of those; you will need to be more 
specific :-)

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

What do you think is left to do here? I can't immediately see the 
difference between what this bug is asking for, and bug 345826.

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

Why do you feel this bug is a priority?

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

What is the problem which bugs you, which this bug would help solve?

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

See my comment in the bug.

Gerv

0
Gervase
6/17/2009 1:53:35 PM
On 17.06.2009 15:43 Uhr, Gervase Markham wrote:
> On 17/06/09 12:35, Ted Mielczarek wrote:
>> This is somewhat confounded by the lack of a standard way to indicate the
>> bug number in your commit message. For example, here's the regex we
>> currently use to linkify bug numbers in commit messages on
>> hg.mozilla.org:
>> http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/buglink.py#l10
>>
>
> Maybe I'm just an old Perl geek, but that regexp looks very simple and
> positively readable to me :-)
>
> Is there a search for the pushlog at the moment?
>
> Gerv
>

The current pushlog doesn't store the comment. I think you can search 
for it in the regular hgweb, though.

My cross-repo pushlog stores the comment, but doesn't expose searching 
that on the web.

Axel
0
Axel
6/17/2009 2:23:21 PM
Gervase Markham <gerv@mozilla.org> wrote:

> On 15/06/09 17:11, Zack Weinberg wrote:
> > It's not always build X - the patch might get backed out.  Yes, in
> > that case the bug is REOPENED, but this is not always obvious in a
> > bug with a long discussion trail.
> 
> Presumably the reopening will be reflected by the fact that the bug
> says REOPEND at the top?

just to clarify - "the bug says REOPENED at the top" is precisely the
thing that is not always obvious in a bug with a long discussion
trail.  You don't want to scroll up and down and up and down,
particularly when the last _relevant_ comment is a couple screens from
the end, followed by chatter and duplication messages.

It'd be great if state changes were always visible in the discussion
trail.  They should be visually deemphasized relative to actual
comments, though.

zw
0
Zack
6/17/2009 3:58:40 PM
On 17/06/2009 14:53, Gervase Markham wrote:
> Hi David,
>
> On 13/06/09 19:29, David E. Ross wrote:
>> First attention should be given to bug reports against Bugzilla in
>> bugzilla.mozilla.org, including RFE bugs.
>
> There are a rather large number of those; you will need to be more
> specific :-)

Yes, but it seems to be fair point in general.  Is someone at some point 
going to look through the large number of RFEs and work out which ones 
are important?  Or will they just sit there gathering cruft until 
someone comes up with the same idea in a discussion like this?  If 
filing RFEs isn't actually driving any work, what is the point in having 
them?  (Same probably applies to Firefox and other products/projects too...)

Michael
0
Michael
6/17/2009 10:32:31 PM
On 17-Jun-09, at 3:32 PM, Michael Lefevre wrote:

> On 17/06/2009 14:53, Gervase Markham wrote:
>> Hi David,
>>
>> On 13/06/09 19:29, David E. Ross wrote:
>>> First attention should be given to bug reports against Bugzilla in
>>> bugzilla.mozilla.org, including RFE bugs.
>>
>> There are a rather large number of those; you will need to be more
>> specific :-)
>
> Yes, but it seems to be fair point in general.  Is someone at some  
> point going to look through the large number of RFEs and work out  
> which ones are important?  Or will they just sit there gathering  
> cruft until someone comes up with the same idea in a discussion like  
> this?  If filing RFEs isn't actually driving any work, what is the  
> point in having them?  (Same probably applies to Firefox and other  
> products/projects too...)

Firefox's RFE evaluation backlog is slowly being ground through, but I  
didn't bother charting it. :)

-- Mike
0
Mike
6/17/2009 11:04:02 PM
On 17/06/09 21:18, Gervase Markham wrote:
> On 14/06/09 08:15, Bradley Baetz wrote:
>> 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.
>
> It might be significant management overhead to maintain such lists. How
> many different ones would we need? One per component? Or product? Are
> the lists of people who accept reviews clearly defined already, or are
> the edges fuzzy?

You could just have one list for all of gecko - this is for autocomplete 
not security.

> Also, practically, to maintain them, you need fairly serious Bugzilla
> privileges - including the ability to add yourself to e.g. the security
> group. So we couldn't really hand them out far and wide...

The ability to put someone into a group is specified on a per-group 
basis (thats how some people can give canconfirm privileges but not 
security group privileges). I don't *think* we support inheritance for 
that (ie allowing anyone in the sr group to add someone to the r= 
group), though.

Bradley
0
Bradley
6/18/2009 5:53:17 AM
On 17.06.2009 13:31, Gervase Markham wrote:
> On 13/06/09 16:06, Peter Weilbacher wrote:
>> 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.
> 
> Sounds like another request for autocomplete to me. Is that right? :-)
> https://bugzilla.mozilla.org/show_bug.cgi?id=490923

Yes, I think autocomplete could work very well.
   P.
0
Peter
6/18/2009 9:52:32 AM
On 17/06/09 16:58, Zack Weinberg wrote:
> just to clarify - "the bug says REOPENED at the top" is precisely the
> thing that is not always obvious in a bug with a long discussion
> trail.

But isn't it right in front of you when the bug loads?

> You don't want to scroll up and down and up and down,
> particularly when the last _relevant_ comment is a couple screens from
> the end, followed by chatter and duplication messages.

Would it help to have the key fields as position:fixed at the top of the 
bug?

> It'd be great if state changes were always visible in the discussion
> trail.  They should be visually deemphasized relative to actual
> comments, though.

There's a bug on that, and it's on the list. Although from a UI 
perspective, perhaps you would have to request it specifically rather 
than it being on by default.

Gerv


0
Gervase
6/18/2009 1:12:23 PM
On 18/06/09 06:53, Bradley Baetz wrote:
> The ability to put someone into a group is specified on a per-group
> basis (thats how some people can give canconfirm privileges but not
> security group privileges).

I stand corrected; you are quite right.

Gerv
0
Gervase
6/18/2009 1:15:34 PM
On 17/06/09 23:32, Michael Lefevre wrote:
> Yes, but it seems to be fair point in general. Is someone at some point
> going to look through the large number of RFEs and work out which ones
> are important?

In the sense you say it, no. RFEs against Bugzilla-the-product could 
have been filed by anyone, and their priorities are not necessarily 
those of the Mozilla project, the focus of this exercise. I want to find 
out what the Mozilla project needs, and the best way to do this is to 
start by asking people, rather than by triaging a large number of RFEs.

> Or will they just sit there gathering cruft until someone
> comes up with the same idea in a discussion like this? If filing RFEs
> isn't actually driving any work, what is the point in having them? (Same
> probably applies to Firefox and other products/projects too...)

Bugzilla will need significantly more development resource in order to 
triage and consider all the outstanding RFEs. Strengthening the Bugzilla 
community is one of our aims in this process.

Gerv

0
Gervase
6/18/2009 1:17:54 PM
Gervase Markham wrote:
> On 17/06/09 16:58, Zack Weinberg wrote:
>> just to clarify - "the bug says REOPENED at the top" is precisely the
>> thing that is not always obvious in a bug with a long discussion
>> trail.
> 
> But isn't it right in front of you when the bug loads?

That depends on whether you followed a link to a specific comment or 
not...  (that said; I've never had a strong yen to know the bug's 
current status while reading it).

> Would it help to have the key fields as position:fixed at the top of the 
> bug?

If there are very few such key fields, possibly...  Ideally this would 
be user-configurable.  I'd sort of like the "resolve this bug" UI to be 
always present, myself.  ;)  And the keywords, since typically I have to 
edit both of those at the same time while making a comment (e.g. for any 
branch checkin I do), and right now that requires some annoying scrolling.

-Boris
0
Boris
6/18/2009 1:19:36 PM
On 06/17/2009 04:07 PM, Gervase Markham wrote:
> On 16/06/09 08:53, Dennis Melentyev wrote:
>> So, for me it is really helpful to have more verbose RSS feeds on bug
>> searches. It's quite the same needs as requested for bugmail (comments,
>> field changes).
>
> Bug searches are about the status of bugs at a particular time; bug mail
> is about the changes made at a particular time. I can't quite see how
> you could combine the two without confusion. Can you give more details
> about what you mean (i.e. what happens now and what could happen in your
> ideal future)?

Well, that's almost no reason to describe what happens now, since that's 
definitely not what I hoped for when tried to do.

Generally, I'd like to have some kind of release activity timeline on 
some scope of bugs, defined by a search.
Bugmail could also be helpful, but in the case of subscribing not to the 
bug, but search (or tag, milestone, etc).

More precisely, I'm interested in status changes (including new bugs 
openings, review requests), new comments to bugs defined by "TB3b3 
blockers" search (one can be found at weekly status meetings page), 
without need to CC/visit each bug.
That's more like general project activity monitoring. Ideally, 
accompanied with agile-like "sprint burndown chart", but that's really 
optional.

/dennis
0
Dennis
6/18/2009 1:26:31 PM
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, 
> 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.

Here's an easy one: add Core to the pretty picker. :)
   https://bugzilla.mozilla.org/show_bug.cgi?id=384603

~fantasai
0
fantasai
6/19/2009 12:29:50 AM
Gervase Markham wrote:
> On 13/06/09 14:04, Robert Kaiser wrote:
>> 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.
>
> That sounds a bit dangerous; you'd end up with attachments which said
> "review+: gerv", which I hadn't actually reviewed. It would be up to the
> honesty of the patch submitter to not submit something entirely
> different...

What if the "forward reviews from this obsoleted patch" would be 
displayed as "gerv(fwd): review+" or something like that? Right now, it 
shows "kairo: review+" and I still check it in with "r=gerv" in the 
checkin comment...

Robert Kaiser
0
Robert
6/19/2009 12:31:30 AM
Max wrote:
> On Jun 14, 3:24 pm, Robert Kaiser<ka...@kairo.at>  wrote:
>> I painfully learned today that mass-changes are quite slow (I did a
>> status change and a comment post) right now in our Bugzilla,
>
>    Hmmm, that actually shouldn't be the case. It's possible that there
> are some customizations to bmo that are causing this.

LpSolit was around when I did run into the problems and saw the pain 
happening, he also said it shouldn't be that way, but he might be able 
to tell you more in detail what we saw.

I'm not saying that Bugzilla itself has a problem, but we definitely 
saw/see it on bmo.

Robert Kaiser
0
Robert
6/19/2009 12:39:04 AM
Gervase Markham wrote:
> On 16/06/09 08:53, Dennis Melentyev wrote:
>> So, for me it is really helpful to have more verbose RSS feeds on bug
>> searches. It's quite the same needs as requested for bugmail (comments,
>> field changes).
>
> Bug searches are about the status of bugs at a particular time; bug mail
> is about the changes made at a particular time. I can't quite see how
> you could combine the two without confusion. Can you give more details
> about what you mean (i.e. what happens now and what could happen in your
> ideal future)?

Not sure what he was talking about, but it would be interested if one 
could get bugmail for changes to a particular query, i.e. "watching" a 
bug list.

Robert Kaiser
0
Robert
6/19/2009 12:44:50 AM
Dennis Melentyev wrote:
> Generally, I'd like to have some kind of release activity timeline on
> some scope of bugs, defined by a search.
> Bugmail could also be helpful, but in the case of subscribing not to the
> bug, but search (or tag, milestone, etc).
> 
> More precisely, I'm interested in status changes (including new bugs
> openings, review requests), new comments to bugs defined by "TB3b3
> blockers" search (one can be found at weekly status meetings page),
> without need to CC/visit each bug.
> That's more like general project activity monitoring. Ideally,
> accompanied with agile-like "sprint burndown chart", but that's really
> optional.

A first stab at what you want might be the popular
https://bugzilla.mozilla.org/show_bug.cgi?id=278455
(Ability to "watch" based on any field)

As long as your searches are only 1 term you're golden: "Component ==
DOM" or  "flag == blocking-firefox3.5+"
0
Daniel
6/19/2009 10:04:39 PM
On 06/20/2009 01:04 AM, Daniel Veditz wrote:
> Dennis Melentyev wrote:
>> Generally, I'd like to have some kind of release activity timeline on
>> some scope of bugs, defined by a search.
>> Bugmail could also be helpful, but in the case of subscribing not to the
>> bug, but search (or tag, milestone, etc).
>>
>> More precisely, I'm interested in status changes (including new bugs
>> openings, review requests), new comments to bugs defined by "TB3b3
>> blockers" search (one can be found at weekly status meetings page),
>> without need to CC/visit each bug.
>> That's more like general project activity monitoring. Ideally,
>> accompanied with agile-like "sprint burndown chart", but that's really
>> optional.
>
> A first stab at what you want might be the popular
> https://bugzilla.mozilla.org/show_bug.cgi?id=278455
> (Ability to "watch" based on any field)
>
> As long as your searches are only 1 term you're golden: "Component ==
> DOM" or  "flag == blocking-firefox3.5+"

Well, it could be a partial solution to what I need, but would rather 
not vote for this bug. As I said, "Bugmail could also be helpful".

But for me, there are at least 2 reasons to go with RSS:
- process_bug has nothing to do with myriads of user-defined 
notification rules
- More distributed load on DB. Just search for things happen within the 
time range and only based on one user settings.

Also, I do not need another ton of e-mails to join my daily ones. RSS 
allows you to have a quick look at summary of changes on interesting 
subjects w/o downloading all the info.

I'm talking about just another approach at least for army of lurkers. So 
it must be easy to setup/use and not bring the serious performance 
impact in.

PS. To be more constructive here, I'd like to ask you to tell me if 
above sounds interesting and I'd file another RFE.
Otherwise, I'm just wasting your time, which is the last thing on my mind.

/dennis
0
Dennis
6/21/2009 10:48:02 PM
On 19/06/09 01:31, Robert Kaiser wrote:
> What if the "forward reviews from this obsoleted patch" would be
> displayed as "gerv(fwd): review+" or something like that? Right now, it
> shows "kairo: review+" and I still check it in with "r=gerv" in the
> checkin comment...

Hmm. Perhaps that would work from a UI perspective. But I'm still seeing 
this as a lot of work for not very much gain in time saved :-|

Gerv

0
Gervase
6/22/2009 11:17:20 AM
On 19/06/09 01:44, Robert Kaiser wrote:
> Not sure what he was talking about, but it would be interested if one
> could get bugmail for changes to a particular query, i.e. "watching" a
> bug list.

I admit my RSS/Atom understanding is less than it used to be, but are 
Atom feeds ordered? If not, doesn't getting a buglist as an Atom feed do 
roughly what you want - i.e. "watch" a query? When new bugs show up, 
they'll appear as unread items in your feed reader?

E.g. (yes, shorter URLs would be good, they've been implemented): 
https://bugzilla.mozilla.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=Governance&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=component&field-1-1-0=resolution&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&query_format=advanced&remaction=&resolution=---&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=Governance&value-1-1-0=---&value0-0-0=&votes=&title=Bug%20List&ctype=atom

Gerv

0
Gervase
6/22/2009 11:20:31 AM
On 06/22/2009 02:20 PM, Gervase Markham wrote:
> On 19/06/09 01:44, Robert Kaiser wrote:
>> Not sure what he was talking about, but it would be interested if one
>> could get bugmail for changes to a particular query, i.e. "watching" a
>> bug list.
>
> I admit my RSS/Atom understanding is less than it used to be, but are
> Atom feeds ordered? If not, doesn't getting a buglist as an Atom feed do
> roughly what you want - i.e. "watch" a query? When new bugs show up,
> they'll appear as unread items in your feed reader?
>
> E.g. (yes, shorter URLs would be good, they've been implemented):
> https://bugzilla.mozilla.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=Governance&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=component&field-1-1-0=resolution&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&query_format=advanced&remaction=&resolution=---&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=Governance&value-1-1-0=---&value0-0-0=&votes=&title=Bug%20List&ctype=atom

Yes, that's the way I use it now. But it misses bug closing (I could be 
wrong here) and also require me to click on links to see what's changed 
in the bug (comments, statuses, etc).
The only useful info is the time of the last change, but it is still 
relative to the date of item. E.g. "Sat 03:08" w/o exact date and timezone.

/dennis
0
Dennis
6/22/2009 12:35:33 PM
Gervase Markham wrote:
> On 19/06/09 01:31, Robert Kaiser wrote:
>> What if the "forward reviews from this obsoleted patch" would be
>> displayed as "gerv(fwd): review+" or something like that? Right now, it
>> shows "kairo: review+" and I still check it in with "r=gerv" in the
>> checkin comment...
>
> Hmm. Perhaps that would work from a UI perspective. But I'm still seeing
> this as a lot of work for not very much gain in time saved :-|

It would gain clarity in what's up, but that's all. It just was a "would 
be nice" idea that came up when thinking about what annoys me in 
Bugzilla. No need to prioritize it.

Robert Kaiser
0
Robert
6/22/2009 1:22:59 PM
On 12.06.2009 13: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.

Something nice to have would be the possibility to be able to reply to
a notification mail to add a comment to a bug, I have forgotten which
one but some other bug tracker can do that. I missed that when I started
using Bugzilla some years ago, and recently I often find myself with
email access but not web (or without my Bugzilla password handy). Just
being able to reply to bugs via email would help in those cases.

   Peter.
0
Peter
6/24/2009 9:09:15 PM
Peter Weilbacher <newsspam@weilbacher.org> wrote:
> On 12.06.2009 13:35, Gervase Markham wrote:
> 
> Something nice to have would be the possibility to be able to reply to
> a notification mail to add a comment to a bug, I have forgotten which
> one but some other bug tracker can do that. I missed that when I
> started using Bugzilla some years ago, and recently I often find
> myself with email access but not web (or without my Bugzilla password
> handy). Just being able to reply to bugs via email would help in
> those cases.

I'd like to second this one.

I know that this has stalled in the past on a perceived requirement for
the ability to make arbitrary changes to bug state via mail, so let me
add that I would be satisfied with appending comments by mail, and that
adding attachments by attaching them to the mail would be the most
useful additional capability.

zw
0
Zack
6/24/2009 10:57:35 PM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful. 

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

Today, b.m.o makes it easy to find a patch (or a bug with a patch) that is
awaiting review, but once the review is done, the patch and its bug drops
off the radar.  Consequently, we have lots of review patches that fail to
get committed in a timely fashion.

It's difficult to find the bugs that have one or more patches, any one of
which meets all of these criteria:

- attachment is a patch
- not obsolete
- written by me
- r+ (and/or sr+)
- not r- and not sr-  (patches can be both r+ and r-)
- not checked in
- attached to a bug that is not resolved, verified or closed

I have a search that looks for bugs that meet all these criteria:

status is one of: unconfirmed, new, assigned, reopened,
attachment data        - changed by                 - me
attachment is patch    - is equal to                - 1
attachment is obsolete - is not equal to            - 1
attachment description - contains none of the words - checked committed
flag                   - contains the string        - review+
                         (note: this also matches superreview+)

and it finds bugs that do not have any single patch that meets those
criteria, but that collectively meet those criteria.  :(

The NSS team changes the bug description to include the words "checked in"
or "committed" to facilitate such searches, but this is less than ideal.

Bug 180812 was filed about this in 2002.  I added comment 6 to it two years
ago. Whistling Dixie would have been as effective and more fun!

I have taken to filtering my bug mail so that all messages that tell me
about review granted or review denied go into a special folder.  That is
the best I can do to work around the problem.

So, I propose that attachments need a "next step" field, that would be
one of
"get review"
"get superreview"
"get checking approval"
"get checked in"
"get re-written"  :)

Any reviewer could set that to any of those values.  Then you could search
for a bug in the "get checked in" state and find all the patches that are
ready to be committed.  By allowing reviewers to set any of those values,
you allow projects with their own rules to bypass unnecessary steps, e.g.
NSS never needs "approval", so it could be bypassed.
0
Nelson
6/25/2009 4:24:38 AM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful. 

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

Please add a "see also" field to hold bug numbers.  Many times, a bug is
related to other bugs that neither block, nor are blocked by, that bug,
but contain very relevant information.  Today, we must artificially claim
that such bugs either block or are blocked by this bug to make them
findable.  That's double-plus ungood.

Also, as a special case of that "see also" field, a field named
"regression caused by bug" that lists the number(s) of bug(s) whose "fixes"
caused this bug, would be helpful.
0
Nelson
6/25/2009 4:28:45 AM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful. 

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

Make searches for the major products (Firefox, Thunderbird, etc.) also
search the "products" on which they depend (e.g. core, NSS, NSPR) so that
people who don't know about all those dependencies, but who do try to
avoid filing duplicates, have a chance of finding duplicates.
0
Nelson
6/25/2009 4:31:31 AM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful.

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

Do something to reduce the huge number of bugs that are filed with the
"security sensitive" flag set for no reason.

Suggestion: when the user checks the "security sensitive" flag, put up a
dialog that explains that security sensitive bugs are only those that can
do certain damage to all users (explain what that is), and make them check
a box, or type in a string (capcha-like), to proceed.
0
Nelson
6/25/2009 4:35:56 AM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful.

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

Settle, once and for all, whether the search page is named "search" or
"query" and fix ALL the links and page names to be consistent.

Change the "And" and "Or" buttons in the search/query form so that, instead
of submitting a form to the server and getting back a new page with a new
form that is partially filled in, they change the form dynamically.

Change the search/query page's submit action so that it reduces the
submitted query to the minimum query, removing any empty search expressions
similar to what Jesse Ruderman's "Shorten Bug Query" bookmarklet does.
If done correctly, this would obviate that bookmarklet.
0
Nelson
6/25/2009 4:42:49 AM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful. 

> Please say what the change you are requesting is, and why making it 
> would improve your life. 

Count votes against a particular bugzilla bug.  This is bug 48570.

Bugzilla is highly biased towards changing things.  It gives a large
voice to the few that want change, and none to the many that want to
leave well enough alone.  Fix that.
0
Nelson
6/25/2009 4:46:10 AM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful. 

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

Give me an email pref that will add me to the CC list of any bug when I
am asked to review a patch attached to that bug.  Not all reviewers will
want that, but I do, so make it an email pref.
0
Nelson
6/25/2009 4:48:19 AM
On 2009-06-12 04:35 PDT, 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, 
> asking people's opinion about which possible improvements would be most 
> useful. 

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

Don't let review requests be submitted unless a matching reviewer name
or email address is found.

We have a terrible problem with people attaching patches and requesting
review, but entering a misspelled or inaccurate email address.  The result
is a patch awaiting review for a long time, and not showing up on any
one reviewer's queue.

So, when a user requests review and b.m.o cannot identify the reviewer,
bounce it back, and make the user correct the review request.  Maybe
autocomplete, if it really is autocomplete, would help here.
0
Nelson
6/25/2009 4:53:17 AM
On 25.06.2009 06:48, Nelson Bolyard wrote:

> Give me an email pref that will add me to the CC list of any bug when I
> am asked to review a patch attached to that bug.  Not all reviewers will
> want that, but I do, so make it an email pref.

Yes, that would be nice. I do that by hand, but that's annoying and adds
unnecessary "bug spam".
   Peter.
0
Peter
6/25/2009 8:15:31 AM
On 06/25/2009 07:24 AM, Nelson Bolyard wrote:
> On 2009-06-12 04:35 PDT, 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,
>> asking people's opinion about which possible improvements would be most
>> useful.
>
>> 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.
>
> Today, b.m.o makes it easy to find a patch (or a bug with a patch) that is
> awaiting review, but once the review is done, the patch and its bug drops
> off the radar.  Consequently, we have lots of review patches that fail to
> get committed in a timely fashion.
>
> It's difficult to find the bugs that have one or more patches, any one of
> which meets all of these criteria:
>
> - attachment is a patch
> - not obsolete
> - written by me
> - r+ (and/or sr+)
> - not r- and not sr-  (patches can be both r+ and r-)
> - not checked in
> - attached to a bug that is not resolved, verified or closed
>
> I have a search that looks for bugs that meet all these criteria:
>
> status is one of: unconfirmed, new, assigned, reopened,
> attachment data        - changed by                 - me
> attachment is patch    - is equal to                - 1
> attachment is obsolete - is not equal to            - 1
> attachment description - contains none of the words - checked committed
> flag                   - contains the string        - review+
>                           (note: this also matches superreview+)
>
> and it finds bugs that do not have any single patch that meets those
> criteria, but that collectively meet those criteria.  :(
>
> The NSS team changes the bug description to include the words "checked in"
> or "committed" to facilitate such searches, but this is less than ideal.
>
> Bug 180812 was filed about this in 2002.  I added comment 6 to it two years
> ago. Whistling Dixie would have been as effective and more fun!
>
> I have taken to filtering my bug mail so that all messages that tell me
> about review granted or review denied go into a special folder.  That is
> the best I can do to work around the problem.
>
> So, I propose that attachments need a "next step" field, that would be
> one of
> "get review"
> "get superreview"
> "get checking approval"
> "get checked in"
> "get re-written"  :)
>
> Any reviewer could set that to any of those values.  Then you could search
> for a bug in the "get checked in" state and find all the patches that are
> ready to be committed.  By allowing reviewers to set any of those values,
> you allow projects with their own rules to bypass unnecessary steps, e.g.
> NSS never needs "approval", so it could be bypassed.

Looks quite close to my request for RSS-watching a set of bugs (search 
results), but more specific to development process and approaching from 
different side.
The very right word here - a "bug radar" or "dashboard" with bugs of 
interest, ideally not requiring me to login to B.M.O. each time.

/dennis
0
Dennis
6/25/2009 8:35:02 AM
On 24/06/09 22:09, Peter Weilbacher wrote:
> Something nice to have would be the possibility to be able to reply to
> a notification mail to add a comment to a bug, I have forgotten which
> one but some other bug tracker can do that.

Debian's bug tracker mostly works this way. Bugzilla has had a 
contributed email interface in the past; I'm not sure whether it's 
currently maintained.

My concern about this, apart from the added maintenance issues, would be 
authentication, which it's very hard to do properly without crypto. 
Also the fact that comments would be likely to acquire quoting detritus 
because people don't trim properly.

Gerv
0
Gervase
6/25/2009 9:26:03 AM
On 25/06/09 05:24, Nelson Bolyard wrote:
> Today, b.m.o makes it easy to find a patch (or a bug with a patch) that is
> awaiting review, but once the review is done, the patch and its bug drops
> off the radar.  Consequently, we have lots of review patches that fail to
> get committed in a timely fashion.

The way I would expect that to work is that the patch author, who should 
be the assignee, would either check it in, once he received the 
"review+" mail, or he would seek someone else to do so.

Are you talking about patches from external contributors?

The Firefox project has a "checkin-needed" keyword which patch authors 
can add to bugs, and which is regularly scanned for.

> I have a search that looks for bugs that meet all these criteria:
>
> status is one of: unconfirmed, new, assigned, reopened,
> attachment data        - changed by                 - me
> attachment is patch    - is equal to                - 1
> attachment is obsolete - is not equal to            - 1
> attachment description - contains none of the words - checked committed
> flag                   - contains the string        - review+
>                           (note: this also matches superreview+)
>
> and it finds bugs that do not have any single patch that meets those
> criteria, but that collectively meet those criteria.  :(

Ah, the complexities of providing a UI to define all possible searches 
on a complex data set :-) Did you make sure you ANDed all the attachment 
terms together rather than putting each of them in a new chart?

This seems to work for me:

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=attach_data.thedata&type0-0-0=changedby&value0-0-0=nelson%40bolyard.me&field0-1-0=attachments.ispatch&type0-1-0=equals&value0-1-0=1&field0-2-0=attachments.isobsolete&type0-2-0=notequals&value0-2-0=1&field0-3-0=attachments.description&type0-3-0=nowords&value0-3-0=checked+committed&field0-4-0=flagtypes.name&type0-4-0=substring&value0-4-0=review%2B

Is it what you want?
	
> So, I propose that attachments need a "next step" field, that would be
> one of
> "get review"
> "get superreview"
> "get checking approval"
> "get checked in"
> "get re-written"  :)

IMO, if there's a "next step" field, it should be per-bug, not 
per-attachment. And that's Jesse's proposal, which is already on the list.

Gerv

0
Gervase
6/25/2009 9:44:08 AM
On Thu, Jun 25, 2009 at 12:26 PM, Gervase Markham<gerv@mozilla.org> wrote:
> My concern about this, apart from the added maintenance issues, would be
> authentication, which it's very hard to do properly without crypto. Also the
> fact that comments would be likely to acquire quoting detritus because
> people don't trim properly.

Given that we've experimented with a quoting feature in bugzilla
itself, and i think i can show that people manage to mess bugs up by
using it, this is indeed a serious concern.

iow. please no.

you must be <this high> to enter.

if you're unwilling to read the bug, and if you're unwilling to
realize how large the bug already is, and consider the fact that your
extra comment will make it even harder for the next person, then i
don't want you to have a way to comment.

comments cost people something (quite a lot actually).
0
timeless
6/25/2009 9:47:49 AM
On 25/06/09 05:28, Nelson Bolyard wrote:
> Please add a "see also" field to hold bug numbers.  Many times, a bug is
> related to other bugs that neither block, nor are blocked by, that bug,
> but contain very relevant information.  Today, we must artificially claim
> that such bugs either block or are blocked by this bug to make them
> findable.  That's double-plus ungood.
>
> Also, as a special case of that "see also" field, a field named
> "regression caused by bug" that lists the number(s) of bug(s) whose "fixes"
> caused this bug, would be helpful.

Another tracker I have used allows one to define bug "relationships" - 
directional links between bugs, and then link bugs together with them.

Blocks: 23456, 68368
Duplicate of: 12578
Regression from: 45257

This sort of mechanism could replace our existing dependency and 
duplicate relationships with something more generic.

I think this is:
https://bugzilla.mozilla.org/show_bug.cgi?id=251556

Gerv
0
Gervase
6/25/2009 9:47:58 AM
On 25/06/09 05:31, Nelson Bolyard wrote:
> Make searches for the major products (Firefox, Thunderbird, etc.) also
> search the "products" on which they depend (e.g. core, NSS, NSPR) so that
> people who don't know about all those dependencies, but who do try to
> avoid filing duplicates, have a chance of finding duplicates.

Yes, whatever search interface new people use should do this magically 
under the covers.

Gerv
0
Gervase
6/25/2009 9:49:03 AM
On Thu, Jun 25, 2009 at 12:44 PM, Gervase Markham<gerv@mozilla.org> wrote:
> The way I would expect that to work is that the patch author, who should be
> the assignee, would either check it in, once he received the "review+" mail,
> or he would seek someone else to do so.

I sure don't do this. I can't. Among the many problems, I don't
actually get mail for review+, and people watching me can't get mail
on my behalf.

> Are you talking about patches from external contributors?

Well, at the very least it happens w/ core people. I know, I've
written patches for NSS (and now JSS!).

> The Firefox project has a "checkin-needed" keyword which patch authors can
> add to bugs, and which is regularly scanned for.

that's clearly a state which nelson is asking for, preferably to
happen automatically. Having to manually tag through is the cost that
requires someone to realize it's ready for it.

And note that you can't add a keyword from the edit attachment page.
Being able to change more of the bug would alleviate that
considerably.
0
timeless
6/25/2009 9:50:29 AM
On 25/06/09 05:35, Nelson Bolyard wrote:
> Do something to reduce the huge number of bugs that are filed with the
> "security sensitive" flag set for no reason.

Are you able to quantify "huge"? When I was watching the alias which 
gets CCed on all security bugs, I didn't see many false positives flow 
past. Some examples would also help to demonstrate what sort of users 
are making this mistake.

Gerv

0
Gervase
6/25/2009 10:04:56 AM
On 25/06/09 05:42, Nelson Bolyard wrote:
> Settle, once and for all, whether the search page is named "search" or
> "query" and fix ALL the links and page names to be consistent.

:-) I think it's called search everywhere but the URL. If not, I agree 
it should be made consistent.

> Change the "And" and "Or" buttons in the search/query form so that, instead
> of submitting a form to the server and getting back a new page with a new
> form that is partially filled in, they change the form dynamically.

That would be nice, wouldn't it? :-) 
https://bugzilla.mozilla.org/show_bug.cgi?id=41652 . You seem to have a 
knack of discovering 5-digit bug numbers ;-)

> Change the search/query page's submit action so that it reduces the
> submitted query to the minimum query, removing any empty search expressions
> similar to what Jesse Ruderman's "Shorten Bug Query" bookmarklet does.
> If done correctly, this would obviate that bookmarklet.

I believe Bugzilla 3.4 does this. We hope to upgrade b.m.o. to it in the 
next few months.

Gerv
0
Gervase
6/25/2009 10:07:22 AM
On 25/06/09 05:46, Nelson Bolyard wrote:
> Count votes against a particular bugzilla bug.  This is bug 48570.
>
> Bugzilla is highly biased towards changing things.  It gives a large
> voice to the few that want change, and none to the many that want to
> leave well enough alone.  Fix that.

I would not lose sleep over the fact that a lot of people have voted for 
a bug you don't like. Votes are only one factor (and often not a 
significant one) that the people actually doing the work take into account.

Gerv
0
Gervase
6/25/2009 10:08:18 AM
On 25/06/09 05:48, Nelson Bolyard wrote:
> On 2009-06-12 04:35 PDT, 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,
>> asking people's opinion about which possible improvements would be most
>> useful.
>
>> 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.
>
> Give me an email pref that will add me to the CC list of any bug when I
> am asked to review a patch attached to that bug.  Not all reviewers will
> want that, but I do, so make it an email pref.

https://bugzilla.mozilla.org/show_bug.cgi?id=301656 , which you filed 
:-) Although you say in that bug "But if I'm not on the CC list, I may 
or may not get *any* emails." You should always get the mail saying that 
someone has asked for for review, assuming you have the "Email me when 
someone asks me to set a flag" preference checkbox checked in email 
preferences.

Gerv
0
Gervase
6/25/2009 10:10:23 AM
On 25/06/09 05:53, Nelson Bolyard wrote:
> We have a terrible problem with people attaching patches and requesting
> review, but entering a misspelled or inaccurate email address.  The result
> is a patch awaiting review for a long time, and not showing up on any
> one reviewer's queue.

I'm not sure why you say "misspelled"; Bugzilla won't let you assign a 
review request to something that is a non-email-address.

If you are saying they pick the wrong person, then yes, that's a 
problem, and it's on the list :-)
https://wiki.mozilla.org/BugzillaImprovements#JavaScript_Autocomplete

Gerv
0
Gervase
6/25/2009 10:13:17 AM
On 25/06/09 10:50, timeless wrote:
> On Thu, Jun 25, 2009 at 12:44 PM, Gervase Markham<gerv@mozilla.org>  wrote:
>> The way I would expect that to work is that the patch author, who should be
>> the assignee, would either check it in, once he received the "review+" mail,
>> or he would seek someone else to do so.
>
> I sure don't do this. I can't. Among the many problems, I don't
> actually get mail for review+, and people watching me can't get mail
> on my behalf.

Do you have the user preference "Email me when someone sets a flag I 
asked for" checked?

>> Are you talking about patches from external contributors?
>
> Well, at the very least it happens w/ core people. I know, I've
> written patches for NSS (and now JSS!).

Sorry, I was insufficiently clear. When I said "external contributors", 
I meant external to the NSS team, because their CVS partition is locked 
down.

> that's clearly a state which nelson is asking for, preferably to
> happen automatically. Having to manually tag through is the cost that
> requires someone to realize it's ready for it.

Right.

> And note that you can't add a keyword from the edit attachment page.
> Being able to change more of the bug would alleviate that
> considerably.

But we all know where this leads, right? :-) The bug filing page got 
simplified a few years ago, and fields were added back to it, one at a 
time, with a "but I just need this one" argument, until it was more 
complicated than before.

Gerv
0
Gervase
6/25/2009 10:16:28 AM
On Thu, Jun 25, 2009 at 1:16 PM, Gervase Markham<gerv@mozilla.org> wrote:
> Do you have the user preference "Email me when someone sets a flag I asked
> for" checked?

I read mail @gmail.com, the account which does work in bugzilla
doesn't really exist.

@gmail.com, I watch all changes, but I can not watch for request
mails, they do not honor watching.

> Sorry, I was insufficiently clear. When I said "external contributors", I
> meant external to the NSS team, because their CVS partition is locked down.

*shrug*. The same problems exist outside of nss.

> But we all know where this leads, right? :-) The bug filing page got
> simplified a few years ago, and fields were added back to it, one at a time,
> with a "but I just need this one" argument, until it was more complicated
> than before.

So, I'd like to point to colchange.cgi. People are clearly willing to
use greasemonkey scripts to rewrite sites. And colchange.cgi urls are
actually portable (just like jesse's buglist shortening query).

If I could turn on and off fields I need in attachment editing. And
you defaulted to what we have today (or less). I wouldn't care. And
I'd gladly share my settings on my blog so people could choose to
ignore them.
0
timeless
6/25/2009 10:41:45 AM
On 25.06.2009 11:44 Uhr, Gervase Markham wrote:
> On 25/06/09 05:24, Nelson Bolyard wrote:
>> Today, b.m.o makes it easy to find a patch (or a bug with a patch)
>> that is
>> awaiting review, but once the review is done, the patch and its bug drops
>> off the radar. Consequently, we have lots of review patches that fail to
>> get committed in a timely fashion.
>
> The way I would expect that to work is that the patch author, who should
> be the assignee, would either check it in, once he received the
> "review+" mail, or he would seek someone else to do so.
>

I find this hard to track, too. Mostly when the tree is so burning that 
landing the patch falls through my attention span. I usually try to keep 
the r+ mail unread until I have landed the patch, but it's a hack.

Axel
0
Axel
6/25/2009 12:04:08 PM
On Thu, Jun 25, 2009 at 1:13 PM, Gervase Markham<gerv@mozilla.org> wrote:
> On 25/06/09 05:53, Nelson Bolyard wrote:
>>
>> We have a terrible problem with people attaching patches and requesting
>> review, but entering a misspelled or inaccurate email address. =A0The re=
sult
>> is a patch awaiting review for a long time, and not showing up on any
>> one reviewer's queue.
>
> I'm not sure why you say "misspelled"; Bugzilla won't let you assign a
> review request to something that is a non-email-address.

when you create an attachment, you can specify a requestee. if the
thing you enter doesn't match, bugzilla has a problem, you gave it an
attachment, it might be painful for you to find it again. so it has a
choice: drop the attachment, or discard the unresolved requestee.

it chooses, and rightfully so, to drop the requestee, unfortunately,
what it should do is drop you into editing mode and give you another
chance to pick the assignee you wanted, instead it just leaves you
somewhere (typically at the filed bug or something).
0
timeless
6/25/2009 12:09:51 PM
On 25/06/09 8:04 AM, Axel Hecht wrote:
> On 25.06.2009 11:44 Uhr, Gervase Markham wrote:
>> On 25/06/09 05:24, Nelson Bolyard wrote:
>>> Today, b.m.o makes it easy to find a patch (or a bug with a patch)
>>> that is
>>> awaiting review, but once the review is done, the patch and its bug
>>> drops
>>> off the radar. Consequently, we have lots of review patches that fail to
>>> get committed in a timely fashion.
>>
>> The way I would expect that to work is that the patch author, who should
>> be the assignee, would either check it in, once he received the
>> "review+" mail, or he would seek someone else to do so.
>>
>
> I find this hard to track, too. Mostly when the tree is so burning that
> landing the patch falls through my attention span. I usually try to keep
> the r+ mail unread until I have landed the patch, but it's a hack.
>
> Axel

(I haven't read the whole thread, so forgive me if this is unhelpful)

We've got a checked-in flag for attachments in the Release Engineering 
components. Those without checkin access sometimes set checked-in? to 
indicate "this is ready to be checked in". This flag might be useful in 
other components too. Having checked-in-1.9.1 or such may help manage 
multi-branch landings, as well.
0
Ben
6/25/2009 12:35:10 PM
Zack Weinberg wrote:
> Peter Weilbacher <newsspam@weilbacher.org> wrote:
>> On 12.06.2009 13:35, Gervase Markham wrote:
>>
>> Something nice to have would be the possibility to be able to reply to
>> a notification mail to add a comment to a bug, I have forgotten which
>> one but some other bug tracker can do that. [...]
> 
> I'd like to second this one.

Doesn't the GCC bugzilla support adding comments through email?

Gunther
0
Gunther
6/25/2009 3:32:32 PM
timeless wrote:
> if you're unwilling to read the bug, and if you're unwilling to
> realize how large the bug already is, and consider the fact that your
> extra comment will make it even harder for the next person, then i
> don't want you to have a way to comment.

Maybe OT: I do prefer commenting to a bug through email if that is
possible. I really dislike that I have to register to be able to
file a bug or to comment.

Gunther
0
Gunther
6/25/2009 3:44:09 PM
On 25/06/09 16:44, Gunther nikl wrote:
> Maybe OT: I do prefer commenting to a bug through email if that is
> possible. I really dislike that I have to register to be able to
> file a bug or to comment.

You aren't going to get bugmail to reply to if you aren't registered and 
CCed. And there is no way we are going to append arbitrary email to bugs 
as comments! It has to come from an authenticated user.

Gerv
0
Gervase
6/25/2009 3:51:19 PM
Gunther nikl <gni@gecko.de> wrote:

> Zack Weinberg wrote:
> > Peter Weilbacher <newsspam@weilbacher.org> wrote:
> >> On 12.06.2009 13:35, Gervase Markham wrote:
> >>
> >> Something nice to have would be the possibility to be able to
> >> reply to a notification mail to add a comment to a bug, I have
> >> forgotten which one but some other bug tracker can do that. [...]
> > 
> > I'd like to second this one.
> 
> Doesn't the GCC bugzilla support adding comments through email?

It does, but only via a nasty local hack.

zw
0
Zack
6/25/2009 3:55:34 PM
On Jun 24, 2:09=A0pm, Peter Weilbacher <newss...@weilbacher.org> wrote:
> On 12.06.2009 13:35, Gervase Markham wrote:
> Something nice to have would be the possibility to be able to reply to
> a notification mail to add a comment to a bug, I have forgotten which
> one but some other bug tracker can do that. I missed that when I started
> using Bugzilla some years ago, and recently I often find myself with
> email access but not web (or without my Bugzilla password handy). Just
> being able to reply to bugs via email would help in those cases.

  Bugzilla currently has this functionality, but it doesn't currently
have a protection mechanism on it, so it just believes that you are
whoever you say you are in the From header. That's why it's not
enabled on bmo. I suspect the other bug tracker you used does the same
thing, but doesn't have security bugs or just doesn't care.

  Anyhow, we have a bug to add a security mechanism to it (no need to
suggest any, we have it down pretty well), it just hasn't been
implemented yet.

  -Max
0
Max
6/25/2009 11:00:32 PM
On Jun 24, 9:28=A0pm, Nelson Bolyard <NOnelsonS...@NObolyardSPAM.me>
wrote:
> Please add a "see also" field to hold bug numbers.

  This exists in 3.4, although it's a bit more than you asked for--it
takes URLs to Bugzilla bugs in *any* Bugzilla installation.

> Also, as a special case of that "see also" field, a field named
> "regression caused by bug" that lists the number(s) of bug(s) whose "fixe=
s"
> caused this bug, would be helpful.

  Your current bmo has the ability to do that, it just has to be
turned on. I developed this as a customization and it has never been
used.

  -Max
0
Max
6/25/2009 11:01:45 PM
On Jun 24, 9:35 pm, Nelson Bolyard <NOnelsonS...@NObolyardSPAM.me>
wrote:
> Suggestion: when the user checks the "security sensitive" flag, put up a
> dialog that explains that security sensitive bugs are only those that can
> do certain damage to all users (explain what that is), and make them chec=
k
> a box, or type in a string (capcha-like), to proceed.

  This would be a bmo customization to take up with IT.

> Make searches for the major products (Firefox, Thunderbird, etc.) also
> search the "products" on which they depend (e.g. core, NSS, NSPR) so that
> people who don't know about all those dependencies, but who do try to
> avoid filing duplicates, have a chance of finding duplicates.

  This would be a bmo customization to take up with IT.

> Settle, once and for all, whether the search page is named "search" or
> "query" and fix ALL the links and page names to be consistent.

  The URLs will not change, but I believe that the UI says "Search"
everywhere. If not in 3.2 or 3.4, then in 3.6 for sure. (You can
always check at http://landfill.bugzilla.org/bugzilla-tip/ )

> Change the "And" and "Or" buttons in the search/query form so that, inste=
ad
> of submitting a form to the server and getting back a new page with a new
> form that is partially filled in, they change the form dynamically.

   Wow, I can't believe that's not fixed yet. I never use the Boolean
Charts in any complex fashion, so I didn't know.

> Change the search/query page's submit action so that it reduces the
> submitted query to the minimum query, removing any empty search expressio=
ns
> similar to what Jesse Ruderman's "Shorten Bug Query" bookmarklet does.
> If done correctly, this would obviate that bookmarklet.

  This has already been done for 3.4 (and has been noted already in
this thread perhaps twice, but I do understand that it's a long thread
to read).

> Count votes against a particular bugzilla bug.  This is bug 48570.

  The current direction of upstream Bugzilla is to make the entire
voting system into an extension, and remove it from core Bugzilla.
Once that's done, whoever the maintainer is can add new features as
they want.

> Bugzilla is highly biased towards changing things.  It gives a large
> voice to the few that want change, and none to the many that want to
> leave well enough alone.  Fix that.

  What? I think you might be talking about a community issue, here.

> So, when a user requests review and b.m.o cannot identify the reviewer,
> bounce it back, and make the user correct the review request. =A0Maybe
> autocomplete, if it really is autocomplete, would help here.

  The correct solution here is to bounce back patches when they are
small, and do our current activity when they are large. Because of the
way file inputs work in forms, the user has to re-upload the file they
attached if user-matching fails.

  The actual correct solution is to implement AJAX autocomplete, and
then we wouldn't have to worry about it at all. (This has also already
been discussed in this thread and on the Wiki page.)

  -Max
0
Max
6/25/2009 11:08:50 PM
On Jun 25, 1:35=A0am, Dennis Melentyev <dennis.melent...@gmail.com>
wrote:
> Looks quite close to my request for RSS-watching a set of bugs (search
> results),

  You do know that that's possible, right? (bug lists have an Atom
format)

> The very right word here - a "bug radar" or "dashboard" with bugs of
> interest, ideally not requiring me to login to B.M.O. each time.

  QA and L10N at Mozilla already have things like this that they have
implemented, I believe.

  -Max
0
Max
6/25/2009 11:12:06 PM
I'm sorry to sound kvetchy, but:

Could we please, please, please take this discussion to a different  
newsgroup? This newsgroup is meant to be reserved for planning  
discussion about upcoming product releases, not a general discussion  
group on how we can improve tools.

Perhaps dev-tree-management if there's no bugzilla related group?

thanks,
mike
0
Mike
6/25/2009 11:17:28 PM
On 2009-06-25 02:44 PDT, Gervase Markham wrote:
> On 25/06/09 05:24, Nelson Bolyard wrote:
>> Today, b.m.o makes it easy to find a patch (or a bug with a patch) that is
>> awaiting review, but once the review is done, the patch and its bug drops
>> off the radar.  Consequently, we have lots of review patches that fail to
>> get committed in a timely fashion.
> 
> The way I would expect that to work is that the patch author, who should 
> be the assignee, would either check it in, once he received the 
> "review+" mail, or he would seek someone else to do so.

Your scheme depends on the mail message, rather than a search, to find that
info.  But that actually brings up another problem, which is that r+ mails
go to the person who requested the review, not (necessarily) to the bug
assignee or patch contributor.

> Are you talking about patches from external contributors?

Internal and external.

> The Firefox project has a "checkin-needed" keyword which patch authors 
> can add to bugs, and which is regularly scanned for.

I guess we could try to train reviewers to set that when they give a patch
r+.  But it cannot be done in the same page as the page where r+ is given,
so it requires twice as many form submissions.

>> I have a search that looks for bugs that meet all these criteria:
>>
>> status is one of: unconfirmed, new, assigned, reopened,
>> attachment data        - changed by                 - me
>> attachment is patch    - is equal to                - 1
>> attachment is obsolete - is not equal to            - 1
>> attachment description - contains none of the words - checked committed
>> flag                   - contains the string        - review+
>>                           (note: this also matches superreview+)
>>
>> and it finds bugs that do not have any single patch that meets those
>> criteria, but that collectively meet those criteria.  :(
> 
> Ah, the complexities of providing a UI to define all possible searches 
> on a complex data set :-) Did you make sure you ANDed all the attachment 
> terms together rather than putting each of them in a new chart?

Yes.

> This seems to work for me:
> 
> https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=attach_data.thedata&type0-0-0=changedby&value0-0-0=nelson%40bolyard.me&field0-1-0=attachments.ispatch&type0-1-0=equals&value0-1-0=1&field0-2-0=attachments.isobsolete&type0-2-0=notequals&value0-2-0=1&field0-3-0=attachments.description&type0-3-0=nowords&value0-3-0=checked+committed&field0-4-0=flagtypes.name&type0-4-0=substring&value0-4-0=review%2B
> 
> Is it what you want?

No, several of those bugs do not meet the criteria.  Bug 332348 for example
does not contain any patch that I created, has r+, is not obsolete, and
doesn't say "checked" or "committed" in the description, yet it appears in
that list.  Likewise bug 388117.

>> So, I propose that attachments need a "next step" field, that would be
>> one of
>> "get review"
>> "get superreview"
>> "get checkin approval"
>> "get checked in"
>> "get re-written"  :)
> 
> IMO, if there's a "next step" field, it should be per-bug, not 
> per-attachment. And that's Jesse's proposal, which is already on the list.

Bugs often require many patches to be committed before they are completely
fixed.  Patches may come from multiple contributors.  Not all contributors
have checkin privileges.  Each patch has its own place in the progression of
states.
0
Nelson
6/26/2009 1:29:50 AM
On 2009-06-25 05:35 PDT, Ben Hearsum wrote:

> (I haven't read the whole thread, so forgive me if this is unhelpful)
> 
> We've got a checked-in flag for attachments in the Release Engineering 
> components. Those without checkin access sometimes set checked-in? to 
> indicate "this is ready to be checked in". This flag might be useful in 
> other components too. Having checked-in-1.9.1 or such may help manage 
> multi-branch landings, as well.

Oooh, that's a very interesting idea.  Can you cite some bug numbers that
show this?  Sounds like it can all be done on a single form submission from
the attachment details page.
0
Nelson
6/26/2009 1:35:37 AM
On 2009-06-25 16:01 PDT, Max wrote:
> On Jun 24, 9:28 pm, Nelson Bolyard <NOnelsonS...@NObolyardSPAM.me>
> wrote:
>> Please add a "see also" field to hold bug numbers.
> 
>   This exists in 3.4, although it's a bit more than you asked for--it
> takes URLs to Bugzilla bugs in *any* Bugzilla installation.
> 
>> Also, as a special case of that "see also" field, a field named
>> "regression caused by bug" that lists the number(s) of bug(s) whose "fixes"
>> caused this bug, would be helpful.
> 
>   Your current bmo has the ability to do that, it just has to be
> turned on. I developed this as a customization and it has never been
> used.

Is there an existing bug asking for this in b.m.o?
If not, what would I ask for, specifically, in such a bug?
0
Nelson
6/26/2009 1:38:55 AM
On 2009-06-25 16:17 PDT, Mike Beltzner wrote:
> I'm sorry to sound kvetchy, but:
> 
> Could we please, please, please take this discussion to a different  
> newsgroup? This newsgroup is meant to be reserved for planning  
> discussion about upcoming product releases, not a general discussion  
> group on how we can improve tools.
> 
> Perhaps dev-tree-management if there's no bugzilla related group?

Mike, if you read this as a newsgroup (rather than as a mailing list)
you can ignore this thread with a single keystroke.  Even as a mailing
list you can filter out the combination of subject and To address.
0
Nelson
6/26/2009 1:40:51 AM
On 25-Jun-09, at 9:40 PM, Nelson Bolyard wrote:

> Mike, if you read this as a newsgroup (rather than as a mailing list)
> you can ignore this thread with a single keystroke.  Even as a mailing
> list you can filter out the combination of subject and To address.

Not the point. I'm a moderator of this particular newsgroup, and I'm  
saying this thread is off-topic for the group. It's meant to be low- 
volume, focused on project planning, not on discussing potential  
improvements to one of our tools.

The original message actually had follow-up headers set appropriately,  
but not reply-to headers, and it inadvertently forked into a  
discussion here. I was fine with it when it hadn't been drowning out  
other topics, but now it has, people have complained to me as a  
moderator, and I'm taking action.

Gerv: can you please tie this discussion off and propose a place to  
continue the (excellent) discussion? Thanks.

cheers,
mike
0
Mike
6/26/2009 1:44:19 AM
On 2009-06-25 05:09 PDT, timeless wrote:
> On Thu, Jun 25, 2009 at 1:13 PM, Gervase Markham<gerv@mozilla.org> wrote:
>> On 25/06/09 05:53, Nelson Bolyard wrote:
>>> We have a terrible problem with people attaching patches and requesting
>>> review, but entering a misspelled or inaccurate email address.  The result
>>> is a patch awaiting review for a long time, and not showing up on any
>>> one reviewer's queue.
>> I'm not sure why you say "misspelled"; Bugzilla won't let you assign a
>> review request to something that is a non-email-address.
> 
> when you create an attachment, you can specify a requestee. if the
> thing you enter doesn't match, bugzilla has a problem, you gave it an
> attachment, it might be painful for you to find it again. so it has a
> choice: drop the attachment, or discard the unresolved requestee.
> 
> it chooses, and rightfully so, to drop the requestee, unfortunately,
> what it should do is drop you into editing mode and give you another
> chance to pick the assignee you wanted, instead it just leaves you
> somewhere (typically at the filed bug or something).

Right, with a tiny little notice that says something like "requestee not
found".  No BOLD RED 48 point text with dancing bananas!  That notice
goes unnoticed every time.  We have some bug contributors who have this
problem more often than not; that is, more than 50% of their attachments
get empty reviewers.  I try to search for bugs with patches in this state,
but then I run into bug 180812 again. :(
0
Nelson
6/26/2009 2:01:00 AM
On 2009-06-25 16:08 PDT, Max wrote:
> On Jun 24, 9:35 pm, Nelson Bolyard wrote:

>> Count votes against a particular bugzilla bug.  This is bug 48570.
> 
>   The current direction of upstream Bugzilla is to make the entire
> voting system into an extension, and remove it from core Bugzilla.
> Once that's done, whoever the maintainer is can add new features as
> they want.

I'd vote against that change, if I could!

0
Nelson
6/26/2009 2:10:54 AM
On 2009-06-25 18:44 PDT, Mike Beltzner wrote:
> On 25-Jun-09, at 9:40 PM, Nelson Bolyard wrote:
> 
>> Mike, if you read this as a newsgroup (rather than as a mailing list)
>> you can ignore this thread with a single keystroke.  Even as a mailing
>> list you can filter out the combination of subject and To address.
> 
> Not the point. I'm a moderator of this particular newsgroup, and I'm  
> saying this thread is off-topic for the group. It's meant to be low- 
> volume, focused on project planning, not on discussing potential  
> improvements to one of our tools.

Oh!  Suggestion: when you're writing while wearing your moderator hat,
please say so in your message.  I do that in the groups I moderate.

> The original message actually had follow-up headers set appropriately,  
> but not reply-to headers, 

The original message I saw in m.d.a.firefox had its follow-up headers
set to this newsgroup (m.d.planning).  See

news://news.mozilla.org:119/SsGdnR9DX9QcoK_XnZ2dnUVZ_qednZ2d@mozilla.org
http://groups.google.com/group/mozilla.dev.planning/msg/8e5abdfca5151b1b?dmode=source
0
Nelson
6/26/2009 2:22:23 AM
On Jun 25, 6:38=A0pm, Nelson Bolyard <NOnelsonS...@NObolyardSPAM.me>
wrote:
> Is there an existing bug asking for this in b.m.o?

  I thought there was, but I don't see it now.
https://bugzilla.mozilla.org/show_bug.cgi?id=3D405215 would probably be
the most appropriate.

> If not, what would I ask for, specifically, in such a bug?

  That an administrator created a Bug ID field with mutual
relationships for tracking which bug regressed another bug.

  -Max
0
Max
6/26/2009 4:08:59 AM
On 26/06/09 02:44, Mike Beltzner wrote:
> Gerv: can you please tie this discussion off and propose a place to
> continue the (excellent) discussion? Thanks.

Sure. Apologies for setting this group as the follow-up group in the 
first place.

<looks> There isn't really anywhere perfect. <sigh> We're pretty much 
done for the moment, so I'll take any remaining discussions to email. If 
and when I need further feedback, I'll try and think of a better place, 
and just put a pointer here.

Gerv
0
Gervase
6/26/2009 9:41:59 AM

Gervase Markham wrote:
> On 26/06/09 02:44, Mike Beltzner wrote:
>> Gerv: can you please tie this discussion off and propose a place to
>> continue the (excellent) discussion? Thanks.
>
> Sure. Apologies for setting this group as the follow-up group in the 
> first place.
>
> <looks> There isn't really anywhere perfect.

Your right.   The next best option would be meta bug and bugs for each 
of the items that have come up in this discussion, and any new ones that 
people want to add.  That would also help progress to be clear.

-chofmann
> <sigh> We're pretty much done for the moment, so I'll take any 
> remaining discussions to email. If and when I need further feedback, 
> I'll try and think of a better place, and just put a pointer here.
>
> Gerv
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
0
chris
6/26/2009 10:11:16 AM
On Thu, Jun 25, 2009 at 7:08 PM, Max<avatraxiom@gmail.com> wrote:
> =A0This would be a bmo customization to take up with IT.

Those are in-scope for this discussion, no?  Not sure why you're
mentioning that it's a customization or that it should be sent to IT,
when this thread was soliciting both code and configuration changes.

Mike
0
Mike
6/26/2009 4:17:57 PM
On Jun 26, 9:17=A0am, Mike Shaver <mike.sha...@gmail.com> wrote:
> Those are in-scope for this discussion, no? =A0Not sure why you're
> mentioning that it's a customization or that it should be sent to IT,
> when this thread was soliciting both code and configuration changes.

  Yes, but the work that Gerv will be doing will be on upstream
Bugzilla, as I understand it. So I was noting both for his benefit and
the benefit of the group that those particular items would work better
as bmo customizations than as upstream changes.

  -Max
0
Max
6/28/2009 9:44:03 AM
On 28/06/09 10:44, Max wrote:
>    Yes, but the work that Gerv will be doing will be on upstream
> Bugzilla, as I understand it. So I was noting both for his benefit and
> the benefit of the group that those particular items would work better
> as bmo customizations than as upstream changes.

This thread is supposed to be dying, but to clarify: the exact route by 
which any code I write gets to be on b.m.o. is not set in stone. There 
are loads of variables here. But I do have a strong desire that it will 
get upstream - either before or after.

b.m.o. customizations, or modifications to them, are definitely in scope 
for *requirements gathering*.

Gerv
0
Gervase
6/29/2009 9:49:37 AM
One improvement we would like to see is the automatic cross posting
into bugzilla of the fact the at bug fix was landed in hg.  There are
a number of single point failures with coordinating putbacks and bug
updates. Once in a while no bug number is associated with a check-in,
or there is a typo with the bug in the putback log.  Sometimes the bug
isn't immediately updated with the fact that the patch was landed.  It
should be fairly straightforward to have the hg server post a comment
to the associated bug about that fact that a patch was landed for that
bug and what change id was associated with it.  This has several
benefits: fewer things for a developer to remember, less chance for a
mistake or omission, standardized messages that could be queried via
bug search to build lists of which bugs have been checked in and which
haven't.

--Tim

0
timr
6/30/2009 10:31:56 PM
On 30/06/09 23:31, timr wrote:
> One improvement we would like to see is the automatic cross posting
> into bugzilla of the fact the at bug fix was landed in hg.

This would probably be a fix to Hg (a post-commit hook), right? If so, 
do file a bug on IT about it, but I think it's out of scope for what I'm 
doing. Sorry :-)

Gerv

0
Gervase
7/6/2009 9:36:58 AM
On Mon, Jul 6, 2009 at 5:36 AM, Gervase Markham<gerv@mozilla.org> wrote:
> On 30/06/09 23:31, timr wrote:
>>
>> One improvement we would like to see is the automatic cross posting
>> into bugzilla of the fact the at bug fix was landed in hg.
>
> This would probably be a fix to Hg (a post-commit hook), right? If so, do
> file a bug on IT about it, but I think it's out of scope for what I'm doing.
> Sorry :-)

It probably needs some API support for not needing s-g-capable
credentials stored in the clear on the hg server.  This hook/account
would only need privs to append comments (and should avoid mid-airing,
obviously!) not to read anything private.

Mike
0
Mike
7/14/2009 3:18:57 AM
Reply:

Similar Artilces:

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

Advice for improving https://metacpan.org/release/Freecell-App
Hi Shirl (and the esteemed module-authors mailing list), We've talked a little in private about https://metacpan.org/release/Freecell-App after this post to fc-solve-discu= ss - http://tech.groups.yahoo.com/group/fc-solve-discuss/message/1336 - and I mentioned the fact that in the Perl/CPAN community prefer to avoid adding m= ore top-level namespaces on CPAN , and you mentioned that you had to fix t/pod-coverage.t too in case Pod::Coverage was installed, but here is some = more advice from a cursory browse of the code. I'm CCing this message to module-authors@perl.org be...

fnail vs thunderbird(tips to improve thunderbird)
Name: Jithin Pellissery Email: jithinpellsatgmaildotcom Product: Firefox Summary: fnail vs thunderbird(tips to improve thunderbird) Comments: hi this is just a suggestion for thunderbird. u see in gmail we are able to chat with our contacts who are online,is there anyway thunderbird can incorporate this feature into itself?its such a boring to check mail on thunderbird and then go to firefox and check if my contacts are online so that i can chat i hope u understand keep up the good work and lastly how do you manage to do such amazing stuff for free??? Browser...

App needs to open other app (dev help)
Hi there, I have this app, which needs to open another app, and minimize the current = app. Its like you have a link to the app and when you click on it, it opens= it. How to do that in FF OS app? Would creating a href link a good idea? I= f not, then what is the correct way to do it? Thanks ...

Improving the Thunderbird Mail Start Page for Thunderbird 2
The Thunderbird mail start page is woefully out of date. It links to features that were new in Thunderbird 1.0 and 1.5. Nothing about all the new features available to users in Thunderbird 2. We'd like to replace the existing Feature items in the start page with a new list of features. It'd be really nice to highlight the new Thunderbird 2 features in the start page. But fixing this would require us to break the string freeze and is something we are reluctant to do without further conversation with all the localizers. For more details see: https://bugzilla.mozilla.org/show_...

superreview granted: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 220339] Patch that uses MOZ_APP_D
Mark Mentovai <mark@moxienet.com> has granted David Bienvenu <bienvenu@nventure.com>'s request for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 220339: Patch that uses MOZ_APP_DISPLAYNAME for executable https://bugzilla.mozilla.org/attachment.cgi?id=220339&action=edit ------- Additional Comments from Mark Mentovai <mark@moxienet.com> This comment isn't necessary: +# Executable should match ...

superreview denied: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current bran
Mark Mentovai <mark@moxienet.com> has denied Josh Aas <joshmoz@gmail.com>'s request for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ------- Additional Comments from Mark Mentovai <mark@moxienet.com> The app bundle's name is ThunderbirdDebug during a debug build. I'd be pleased to...

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 220339] Patch that uses MOZ_APP #3
David Bienvenu <bienvenu@nventure.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 220339: Patch that uses MOZ_APP_DISPLAYNAME for executable https://bugzilla.mozilla.org/attachment.cgi?id=220339&action=edit ------- Additional Comments from David Bienvenu <bienvenu@nventure.com> you need to request reviews of people - bugzilla should really complain about that! ...

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

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

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 220339] Patch that uses MOZ_APP #2
Chris Andrichak <chris@grope.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 220339: Patch that uses MOZ_APP_DISPLAYNAME for executable https://bugzilla.mozilla.org/attachment.cgi?id=220339&action=edit ------- Additional Comments from Chris Andrichak <chris@grope.com> Getting the executable name from the variable at mark's suggestion, the make file now swaps it into the plist file also....

http://dev.123done.org/ versus http://123done.org/
The first site is looking very good for a model for a prospective RP. Add in the improved password analysis tool and it would be even better. Why doesn't the original site stay in sync? Best regards, -Tom ...

How improve Thunderbird? :)
Name: Paul Product: Thunderbird Summary: How improve Thunderbird? :) Comments: Hello! I'm very satisfied Thunderbird user from Poland. One thing I'm missing within a program is; when you receive new mail with attachments (say coulpe photos from a friend), you can't save all of them at once. You have to save each one one after another. It's quite disturbing when there's a lot of photos to save on a hard drive, and there's no other option than click SAVE AS for each file. I know this option is avalible for example in Outlook Express, although I think Fi...

Thunderbird improvement
Hi, It would be fine to be able to associate a sound with each filter as in Eudora Bye Jean-Marie ...

improving thunderbird
Name: Javier Email: javier061atgmaildotcom Product: Thunderbird Summary: improving thunderbird Comments: I love thunderbird! There's something I'd add to it: the option to disable an account without losing its configuration (outlook express does it I think). Also, I've been always been unable to paste an image in a message. I have to attach it. Keep up the good work! Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2 From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expect...

Web resources about - bugzilla.mozilla.org improvements - mozilla.dev.apps.thunderbird

Seventh Street Improvement Arches - Wikipedia, the free encyclopedia
The Seventh Street Improvement Arches are a double- arched masonry highway bridge that formerly spanned the St. Paul and Duluth Railroad tracks ...

Facebook Chief Security Officer Joe Sullivan: ‘Constant State Of Improvement’
Facebook Chief Security Officer Joe Sullivan hosted reporters at Facebook’s headquarters in Menlo Park , Calif., Tuesday, where he detailed how ...

Chronik-Fotos - Iowa Citizens for Community Improvement - Facebook
At a meeting on August 6, 2013, Constantino told Rep. Latham, “If I am sent back, I will face more violence and I could lose my life. We are ...

Improvements to the Preferred Developer Consultant Program
This February, we opened up a new round of submissions for the PDC program. As businesses across the world look to get smarter about integrating ...

Facebook reveals ad unit improvements, will phase out Questions and Offers products
Facebook has announced plans of streamlining its ad products by simplifying its offerings. From these changes, users will see a more standard ...

Orica flags improvement after $1.2bn loss - AdelaideNow Search Search
EXPLOSIVES maker Orica has flagged improving earnings for this financial year after posting a $1.267 billion full year loss due to a huge asset ...

Apple devices will benefit from Bluetooth improvements for range, speed, & smart apps next year
... the Bluetooth Special Interest Group has shared details on updates planned for the wireless connectivity technology in 2016 including improvements ...

Taking Organizational Improvement Seriously – Case Study
... the system. Before making any change, the team creates a new version of the causal loop diagram to see if their proposed solution is an improvement ...

Taking Organizational Improvement Seriously – Case Study
... the system. Before making any change, the team creates a new version of the causal loop diagram to see if their proposed solution is an improvement ...

Qualcomm Stabilizes in Modems, Intel Needs Improvement in Tablets, Says Wells
Wells Fargo chip analyst David Wong today weighs in with some tidbits on the latest in the wireless chip war between Qualcomm (QCOM) and MediaTek ...

Resources last updated: 12/4/2015 8:52:15 PM