641594 - The bug number exclusion field in the Top Bugs pane doesn't work correctly

Status: RESOLVED FIXED

(Tree Management Graveyard :: OrangeFactor, defect, P1)

Description

[(no longer active)]

See the URL please.  I thought that entering 633566 into the text field should exclude it from the Top Bugs stats (it would make sense since bug 633566 is now fixed), but apparently that does the exact opposite (only includes bug 633566), which is not very useful.  ;-)

Comment 1

[Mark Côté [:mcote]]

Hm yeah, the text fields on all views, except Simulator, just filter what bugs are displayed.  You can more-or-less get the info you're looking for by just looking at the top 11 bugs, though, no?

But we could modify Top Bugs (and probably all the other views) to have both inclusionary and exclusionary filters, if you think that would be useful.

Comment 2

[Mark Côté [:mcote]]

Ah, the text about the entry box is definitely wrong; that'll be the first thing to fix. :)

Comment 3

[(no longer active)]

(In reply to comment #1)
> Hm yeah, the text fields on all views, except Simulator, just filter what bugs
> are displayed.  You can more-or-less get the info you're looking for by just
> looking at the top 11 bugs, though, no?
> 
> But we could modify Top Bugs (and probably all the other views) to have both
> inclusionary and exclusionary filters, if you think that would be useful.

Well, that may be useful, but it doesn't solve my current problem.

I've started to look at and fix the top orange bugs.  I want to exclude the fixed bugs from <http://brasstacks.mozilla.com/orangefactor/?display=TopBugs>, and also some others (like bug 610185) which we cannot do anything for.

Comment 4

[Mark Côté [:mcote]]

Er, but you want the ability to exclude a list of bugs from the graph & table, right?  So if we added a filter that could be used to exclude bugs, you could do what you want by specifying the list of bugs you don't want to see, no?  Or do you mean you'd also like to have an option that would automatically exclude fixed bugs?

Comment 5

[(no longer active)]

(In reply to comment #4)
> Er, but you want the ability to exclude a list of bugs from the graph & table,
> right?  So if we added a filter that could be used to exclude bugs, you could
> do what you want by specifying the list of bugs you don't want to see, no?  Or
> do you mean you'd also like to have an option that would automatically exclude
> fixed bugs?

Both, I guess.  The question that I want to answer is: "Now that I've fixed a bunch of bugs, and I know that I can't do anything for another set of bugs, what are the bugs on which I should focus on to get the most amount of impact out of my time?"

Comment 6

[Mark Côté [:mcote]]

Okay we'll get on that.  Anything to help someone attacking those oranges. :)

Comment 7

[Mark Côté [:mcote]]

Attachment: Add exclusionary filters

This addresses half of this bug by adding a new filter to the Orange Factor, Bug Count, and Top Bugs views which excludes bugs.  You can specify bug numbers or a quicksearch query (remember that you have to preface quicksearch queries with "ALL" if you want to include resolved bugs), and on the Top Bugs view (only), you can enter number of bugs to exclude.

The excluded filter is applied after the included filter, with one exception: in Top Bugs, if you enter in a number of bugs (not bug number) for both the included and excluded filter, you will get the number of bugs specified in the included filter, but with the number of top bugs specified by the excluded filter removed first.  In other words, if you ask to include 15 bugs and exclude 5, you'll get a list of the 6th most active bug to the 20th most active bug.

Comment 8

[Mark Côté [:mcote]]

Ehsan, I hope this helps you out.  Unfortunately filtering resolved/closed bugs is much harder because this information is not available in our ES database.  The problem is that we can't assemble a list of the top X open bugs without asking bzAPI about the status of all the bugs first, which would take a long time (we'd have to do it iteratively because checking the status of all at the same time would choke bzAPI).

However, this prompted an interesting discussion.  We are considering hooking pulse up to our ES database in order to store minimal bug data (status, summary, etc.) about all orange bugs, which would not only make this problem much easier to fix but would also speed up various parts of the site.  We'll let you know how this goes.

Comment 9

[Jonathan Griffin (:jgriffin)]

Comment on attachment 522724 [details] [diff] [review]
Add exclusionary filters

The patch looks good.

One oddity of the implementation is that excluding something via quicksearch only excludes open bugs.  So, for example, if you entered "Test timed out" in the exclude box, the list you'd end up with wouldn't contain any open bugs that contained "Test timed out", but may contain closed bugs that contain that text.

The same constraint is present with the include filter, but it probably makes more sense there.

I wonder, if instead of quicksearch, it might be better to do a straight title search for textual data in the exclude field, which would include bugs of any status?

Comment 10

[Mark Côté [:mcote]]

Well, as I mentioned, you can preface any quicksearch query with "ALL" to include resolved/closed bugs.  Admittedly I had to look at the quicksearch help to find this... maybe I could put it in the placeholder text as a suggestion/reminder?

Comment 11

[Mark Côté [:mcote]]

Okay changed the exclude filter placeholder text to include more examples, including one with "ALL".

Pushed as http://hg.mozilla.org/automation/orangefactor/rev/272bd005d538

Comment 12

[(no longer active)]

This is good enough for now.  I can just remove the fixed bugs myself manually until we get the bug status data for you to use in orange factor.  Thanks for the fix.  When do you think it's going to be pushed live?

Comment 13

[Mark Côté [:mcote]]

Ah sorry, I deployed it just after committing it, so you should see it now.  You might have to refresh the page after loading it, if you have it cached locally.

Comment 14

[(no longer active)]

(In reply to comment #13)
> Ah sorry, I deployed it just after committing it, so you should see it now. 
> You might have to refresh the page after loading it, if you have it cached
> locally.

It doesn't work for me: <http://brasstacks.mozilla.com/orangefactor/?display=TopBugs&inputText=633566&endday=2011-03-14&startday=2011-02-13&dayCount=All&includeFilter=&excludeFilter=582216,%20%20633566,%20%20594666,%20%20618041,%20%20611457,%20%20626168,%20%20614643,%20%20637975,%20%20589502>

Am I missing something?

Comment 15

[Mark Côté [:mcote]]

Oh that looks like a bug that was introduced along with the original include filter.  If you omit the spaces after the commas, it will work, eg 

http://brasstacks.mozilla.com/orangefactor/?display=TopBugs&inputText=633566&endday=2011-03-14&startday=2011-02-13&dayCount=All&includeFilter=&excludeFilter=582216,633566,594666,618041,611457,626168,614643,637975,589502

I'll fix that though, since it should work even with spaces.

Comment 16

[(no longer active)]

(In reply to comment #15)
> Oh that looks like a bug that was introduced along with the original include
> filter.  If you omit the spaces after the commas, it will work, eg 
> 
> http://brasstacks.mozilla.com/orangefactor/?display=TopBugs&inputText=633566&endday=2011-03-14&startday=2011-02-13&dayCount=All&includeFilter=&excludeFilter=582216,633566,594666,618041,611457,626168,614643,637975,589502
> 
> I'll fix that though, since it should work even with spaces.

Beautiful, thanks!

Speaking of that, can you just break on word boundaries instead of only on commas?  That would make this much easier to use.

Comment 17

[Jonathan Griffin (:jgriffin)]

Attachment: let woo_server.py utilize a bz cache

This patch modifies woo_server.py to get all bugzilla data from a bz cache which is already running on brasstacks.  To test it locally, you'll need to install http://hg.mozilla.org/users/jgriffin_mozilla.com/bzcache

woo_server now returns bug data as part of any call to \bybug, so we should further optimize by removing unneeded calls to \bugdetails from js.

Comment 18

[Mark Côté [:mcote]]

Comment on attachment 524292 [details] [diff] [review]
let woo_server.py utilize a bz cache

Awesome, looks good and works perfectly on my machine.

Comment 19

[Jonathan Griffin (:jgriffin)]

woo_server bzcache patch pushed as http://hg.mozilla.org/automation/orangefactor/rev/181c0a1173db

Comment 20

[Mark Côté [:mcote]]

Attachment: Fix metrics and better separate results of /count and /bybug

This separates the returned JSON from /bybug and /count into "oranges" and "bugs".  This also fixes the metrics on various pages.

Comment 21

[Jonathan Griffin (:jgriffin)]

Comment on attachment 526831 [details] [diff] [review]
Fix metrics and better separate results of /count and /bybug

Thanks for doing this.

Comment 22

[Mark Côté [:mcote]]

Pushed as http://hg.mozilla.org/automation/orangefactor/rev/24d332782df5.  Next I'll work on using the "bugs" object to fill in the bugs' table rather than doing a separate query.

Comment 23

[Mark Côté [:mcote]]

Attachment: Use bug info in /bybug where possible

This patch adds the bug info in /bybug to the bug_details store so that we don't have to do a separate query for the details table.

Comment 24

[Jonathan Griffin (:jgriffin)]

Comment on attachment 526850 [details] [diff] [review]
Use bug info in /bybug where possible

I like patches where we can remove code.  :)

Comment 25

[Mark Côté [:mcote]]

Me too. :)

Pushed as http://hg.mozilla.org/automation/orangefactor/rev/f7ff95f08dc7

Comment 26

[Mark Côté [:mcote]]

Attachment: Better bug-list parsing

This patch moves the bug-list parsing into the client JS; previously, anything other than a single number was shipped off to bzAPI (via /bugquery) for parsing.  It now allows comma and/or space separation between bug IDs.  I also renamed the function to something more obvious and added some comments, since it was a bit confusing in there.

Comment 27

[Jonathan Griffin (:jgriffin)]

Comment on attachment 526887 [details] [diff] [review]
Better bug-list parsing

Looks great!

Comment 28

[Mark Côté [:mcote]]

Pushed as http://hg.mozilla.org/automation/orangefactor/rev/546e8fd67cc8 and deployed.

Comment 29

[Mark Côté [:mcote]]

Ehsan: the link you provided in comment 14 should now work.  The filters will also work with space-separated lists of bug IDs, although if you want to get any more complicated you'll have to follow the standard Bugzilla quicksearch format.

Comment 30

[(no longer active)]

(In reply to comment #29)
> Ehsan: the link you provided in comment 14 should now work.  The filters will
> also work with space-separated lists of bug IDs,

Yep, thanks a lot!

> although if you want to get
> any more complicated you'll have to follow the standard Bugzilla quicksearch
> format.

Oh, I didn't know that!  How does this work exactly?  For example, by default when doing quicksearch, Bugzilla searches for open bugs only, which is clearly not the case here.

Comment 31

[Mark Côté [:mcote]]

A quicksearch query is only perofmed if the WOO client JS wasn't able to parse a number or list of numbers out of the input text.  If it *does* recognize the text as being one or more bug IDs, it includes/excludes those bugs regardless of status.  Otherwise the text is passed to quicksearch and you'd have to specify "ALL" if you want to include/exclude closed bugs (e.g. "ALL test timed out").

So to recap, these are the ways the filter fields can be used.  The first two are handled by the WOO code itself; the last is punted off to bzAPI for processing.

- single number, less than 10 000: a number of bugs to include/exclude
  - include N: show N bugs
  - exclude N: omit the top N bugs
  - include N(i) and exclude N(e) (i.e. both filters are numbers less than 10 000): show the N(i) bugs following the top N(e) bugs
   - for example, if N(i) is 10 and N(e) is 15, show the 16th to 25th highest-ranking bugs, inclusive

- single number above 10 000 or a comma- or space-separated list of numbers: include/exclude those specific bugs, open or closed, if they exist.

- anything else: treats the text field as a bugzilla quicksearch query and include/exclude the bugs that match.

I'll see about putting this into a help popup or the like.

Comment 32

[(no longer active)]

(In reply to comment #31)
...

I see, that's pretty cool!

> I'll see about putting this into a help popup or the like.

That would be very helpful indeed.  :-)

Comment 33

[Mark Côté [:mcote]]

Attachment: Filter help dialog

Simple code, but maybe you can make sure the text itself makes sense.

A couple other small things for me to fix w.r.t. filters:
- Orange Factor doesn't allow number-of-bugs, only bug IDs and QuickSearch.  I don't think there's a good reason not to, or at least I can't remember it.  I'll change it to match the other views' filters.
- Centering is off on the Simulator page.

Comment 34

[Jonathan Griffin (:jgriffin)]

Comment on attachment 528258 [details] [diff] [review]
Filter help dialog

Nice, I think the wording is clear.

Comment 35

[Mark Côté [:mcote]]

Attachment: Cleanup in filtering UI and elsewhere

Bunch of changes here:

- Display number of oranges without test-run information, with help dialog.
- Made filters consistent across all views.
- Put Orange Factor dropdowns into  a table with labels.
- Increased graph and tick-font size.
- Consistent 'filtered stats' display.

Comment 36

[Jonathan Griffin (:jgriffin)]

Comment on attachment 528861 [details] [diff] [review]
Cleanup in filtering UI and elsewhere

Review of attachment 528861 [details] [diff] [review]:

Looks good.  One thing I noticed is that during the initial page load, if you don't have anything in your browser's cache, you'll see the dialog text appear briefly on screen before the "Loading..." text appears.  To avoid this, it might be a good idea to apply display: none to #dlgHelpFilter and #dlgHelpOrangeNoTestRun.

Comment 37

[Mark Côté [:mcote]]

Good call.  All the dialog divs are now in a hidden parent div, so no extra rules necessary if we add more dialogs.

Pushed as http://hg.mozilla.org/automation/orangefactor/rev/1061d7724f24 and deployed.