bugzilla.mozilla.org improvements

classic Classic list List threaded Threaded
234 messages Options
1234 ... 12
Reply | Threaded
Open this post in threaded view
|

bugzilla.mozilla.org improvements

Gervase Markham
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Axel Hecht
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Dave Townsend
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 :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Nikolay Shopik
In reply to this post by Gervase Markham
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Gervase Markham
In reply to this post by Axel Hecht
On 12/06/09 12:49, Axel Hecht wrote:
> My pet would be a truly-JSON API to get data out of bugzilla. Our use
> case is the l10n dashboard, which we'd like to have bugilla integrated
> with.

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

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Gervase Markham
In reply to this post by Dave Townsend
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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Mike Shaver
In reply to this post by Gervase Markham
On Fri, Jun 12, 2009 at 9:55 AM, Gervase Markham<[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Andrew Sutherland-3
In reply to this post by Gervase Markham
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

John J Barton
In reply to this post by Gervase Markham
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


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Mike Shaver
On Fri, Jun 12, 2009 at 11:38 AM, John J.
Barton<[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

John J Barton
In reply to this post by Gervase Markham
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Dave Townsend
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Daniel Veditz-2
In reply to this post by Gervase Markham
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

John J Barton
In reply to this post by John J Barton
Mike Shaver wrote:

> On Fri, Jun 12, 2009 at 11:38 AM, John J.
> Barton<[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Benjamin Smedberg
In reply to this post by Gervase Markham
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Mike Shaver
In reply to this post by John J Barton
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 <[hidden email]> wrote:

> Mike Shaver wrote:
>> On Fri, Jun 12, 2009 at 11:38 AM, John J.
>> Barton<[hidden email]> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>

--
Sent from Gmail for mobile | mobile.google.com
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Justin Dolske-2
In reply to this post by Gervase Markham
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Samuel Sidler
In reply to this post by Benjamin Smedberg
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Bugzilla from jruderman@gmail.com
In reply to this post by Gervase Markham
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org improvements

Axel Hecht
In reply to this post by John J Barton
On 12.06.2009 17:52 Uhr, Mike Shaver wrote:

> On Fri, Jun 12, 2009 at 11:38 AM, John J.
> Barton<[hidden email]>  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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 12