mozilla :: #ateam

17 Mar 2017
01:41bcgbrown: are you removing --dm-trans from the unittests as part of bug 1340584 ?
01:42bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1340584 Mozbase, normal, gbrown, NEW , Remove all references to devicemanagerSUT
01:42gbrownyeah
01:42bcIf so, we need to coordinate with autophone since it uses that when invoking them.
01:42bcit's in tests/runtestsremote.py
01:43bcThis will be a problem for me unless you uplift it or I can detect it.
01:44bcThe default was sut previously, right? I have to use it to not invoke the sut?
01:45gbrownyeah. so I think I need to land a simple change to change the dm_trans default to adb, land that, uplift it
01:45gbrownthen remote the reference from autophone and get that deployed
01:45bcYeah. Once you do that, I can remove it from autophone.
01:45gbrownthen proceed with the main patch
01:46bcneeds to uplift to beta, aurora, release
01:46gbrownI can't think of a simpler way to remove --dm_trans; can you?
01:47bcno, the fact we've been working around the default sut for a while is the problem. hard to do both at the same time when you have a consumer like autophone that is outside the tree.
01:47gbrownokay. I may send some simple reviews your way soon.
01:47bcchange default, uplift, update autophone, land main patch i think is the best we can do. removing sut isn't critical fortunately.
01:48bck
09:01marcojgraham: I added the script on https://github.com/marco-c/firefox-code-coverage, so you can submit PRs if you want
09:04jmaher|afk:)
09:07jmaher|afkwhimboo: hey, I didn't realize you were still on webdriver work
09:07jmaher|afkwhimboo: no worries on bug 1303834 right now- is next week something realistic to hack on this?
09:07bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1303834 Firefox UI Tests, normal, nobody, NEW , Intermittent test_fallback_update.py TestFallbackUpdate.test_update | IOError: Process killed because the connection to Marionette server is lost. Check gecko.log for errors (Reason: Timed out waiting for port 2828!)
09:26jgrahammarco: Great. I shared the results with bz who thought that the coverage looked implausibly low
09:26jmaher|afkjgraham: well that is very likely given the fact that we haven't done much to vett the data
09:27jgrahamI think wpt is probably not shutting down the browser in the right way. I have a patch in another branch that I can land
09:27jgrahamjmaher|afk: Right, I'm trying to help with that :) I'm intereseted in these results
09:27jmaher|afk++
09:29jmaher|afkjgraham: I would suspect that once we fix the small number of issues causing us to not get valid coverage (could be compile flags, browser code, test code, lcov.rs stuff) we can have data we trust a lot more
09:30marcojgraham: do you have a bug # for this issue?
09:30jmaher|afkjgraham: also note, that we are not enabling the JSVM coverage, that is coming up *next*; JSVM has a mode built in where it can generate .gcda artifacts for js lines covered
09:31jgrahammarco: It's part of the issue for enabling leak checking in wpt, but I can land this part first
09:31jgrahamSince it's just upstream chnages that Ms2ger already reviewed
09:31marcojgraham: cool; you can try making a try build with that change and see if the code coverage improves
09:32* jgraham doesn't recall the bug number and is on a train
09:32marcoahah, no rush :P
09:32marcowe also have a similar problem with e10s, where content processes are not cleanly exiting
09:32marcoand so the coverage counters are not updated
09:33* jmaher|afk imagines jgraham rushing to race the tube
09:33jmaher|afkmarco: oh, you have already looked at those?
09:36marcojmaher|afk: no, chmanchester did
09:36jmaher|afkok :)
10:29whimboojmaher|afk: cannot say yet. still a P1 left for me to do
10:31jmaher|afkwhimboo: ok, I know that those can sometimes be 'unknown'- we have one for taskcluster osx which is quite frustrating
10:32whimboojmaher|afk: but i hope that bug 1335778 is not that too complex
10:32bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1335778 Marionette, major, nobody, NEW , Make element#click command check for page load and wait
10:32jmaher|afk:)
10:52jgrahamThis auto-artifact build thing should probably be taught that coverage builds can't be artifact builds unless we are uploading artifacts for them
10:53jgraham(on try)
10:57* jgraham files a bug
11:46marcojgraham: btw, can I see the report that you generated?
11:47jgrahammarco: Sure: http://hoppipolla.co.uk/410/coverage.tar.bz2
11:47marcoty
11:56marcojgraham: it is quite low indeed
11:57marcoekyle: ping
11:57ekylemarco: pong
11:58marcoekyle: simple question, the covered and uncovered lines in the records have to be sorted?
11:58ekylemarco: nah, but they will compress better if they are
11:58marcook, I'll leave them sorted then
12:07marcoekyle: regarding https://github.com/marco-c/grcov/issues/14
12:08marcoekyle: I can change it to generate records for not executed functions
12:08marcoand assign the uncovered lines to those records
12:09ekylemarco: looking...
12:10ekylemarco: yes, I do not see a problem with that
12:10marcook, I'll do that then
12:11marcoI will also add the `language` property
12:11marcoand then publish a new release
12:11ekylemarco: there has been some desire for % of functions covered, so that data will help answer that
12:12marcoekyle: is the ingested data visible in the UI now?
12:12ekylemarco: i have not checked the UI yet.
12:13ekylemarco: there is a post processing job that summarized the coverage for the UI: https://github.com/klahnakoski/ActiveData/blob/dev/active_data/jobs/codecoverage.py
12:14ekylemarco: I do not beleive the job belong in the ActiveData repo, so if you have suggestions about where it belongs, I am open to moving it.
12:20marcoekyle: should we drop the `codecoverage` branch in the ActiveData-ETL repo and directly work on the `dev` branch?
12:20ekylemarco, yes but the student work must be merged next, which I will do next week
12:21marcook
12:22marcoekyle: https://github.com/marco-c/grcov/issues/16
12:22marcowhat works best for queries? 100% when we have 0 covered and 0 uncovered?
12:29ekylemarco: null is best
12:29marcook
12:29ekylemarco: or simply not including the property
12:38marcoekyle: same with the orphan percentage?
12:38marcoat the moment, it's doing orphan_covered.len() / max(1, orphan_covered.len() + orphan_uncovered.len())
12:38marco(as this is what the old python code was doing)
12:39marcobut I can change it to be "null" when there are no orphan covered and uncovered lines
12:39ekylemarco: thank you for reminding me what the other code was doing
12:40ekylemarco: the percentage is hardly used, since the aggregate percentages require the original covered/uncovered to calculate
12:40ekylemarco: so `null`/missing is best, but zero does not hurt
12:43marcook, I'll always use null
12:45jgrahammarco: We are merging the files each time the browser restarts, right?
12:46jgrahamDuring a specific test job
12:46marcojgraham: yes
12:46marcojgraham: that's what gcc does automatically
12:46jgrahammarco: Ah, OK, good :)
12:57ekylejgraham: marco good? if we do not merge the files we can know what directory provides what coverage.
13:01marcoekyle: we would need to store one artifact per browser run
13:01marcoit would be a lot of data
13:26jgrahamekyle: "good that it isn't throwing away data after each restart"
13:27jgrahamofc per-whatever data is nicer but simply getting complete data id a good enough first step
13:27ekyleyes, that is good. :)
13:27ekylejgraham: yes, I am not conerned with the per directory data right now, just getting the pipeline to the UI is most important
13:45jmaherekyle: I believe activedata is all up and running; just making sure you believe it is up to date from your end
13:45* jmaher has a small list, but it is updating which makes me think it is working and I have just caught up on things
13:46ekylejmaher: yes it is up to date
13:47jmaherekyle: great
13:47ekylejmaher: sorry you must check everyday
13:47jmaherekyle: no worries, I know the drill
13:47ekylejmaher: I am at least getting alerts when it stops
13:47jmaherekyle: excellent
13:48ekylejmaher: we will soon have a reliable machine: https://bugzilla.mozilla.org/show_bug.cgi?id=1344253
13:48bugbotBug 1344253: is not accessible.
13:48jmaherI have a tendency to want to do a good job and not ignore bugs, so keeping your dashboard up to date is important for me
13:48KWierso|afkjmaher: is there a bug tracking getting bug components into moz.build files throughout the tree?
13:48jmaherekyle: can you cc me
13:48ekylejmaher: ok
13:48jmaherKWierso|afk: https://bugzilla.mozilla.org/show_bug.cgi?id=1328351
13:48bugbotBug 1328351: General, normal, nobody, NEW , [meta] - tracking bug for getting BUG_COMPONENT specified for all files in the tree
13:48KWierso|afkjmaher: thanks
13:48jmaherKWierso|afk: I just need 2 more weeks of work without craziness and I could finish it
13:49KWierso|afkI know that feel
13:49jmaherKWierso|afk: heh; I have come far, I can get a few more directories finished before the end of Q1
13:49KWierso|afkI'd settle for figuring out why this smoke detector is still chirping at me after swapping out the battery twice and hitting the reset button, though
13:53jmaherKWierso|brb: I would rather debug a crash in firefox than that
13:54bcKWierso|brb: It's not a CO detector as well?
13:56* jmaher has the upgraded version that beeps when it hears BS
14:06jgrahammarco: Ah, my data is looking better this titme
14:06jgraham*time
14:07jgrahamI'll replace the old file
14:07marcojgraham: good; you'll replace http://hoppipolla.co.uk/410/coverage.tar.bz2 ?
14:07jgrahamYeah, once it finishes compressing
14:09marcoekyle: the two queries in https://github.com/marco-c/grcov/issues/17 are returning 0 results
14:09ekyleyes, they should return something
14:10marcoekyle: the output of the tool should already be like you described in the issue
14:10marcothe orphan record doesn't have a method name and has file.covered
14:11marcothe method records have a method name and don't have file.covered
14:11ekylemarco: ok, maybe there is a problem somewhere else
14:11ekylemarco: I will keep looking, thanks!
14:15jgrahammarco: Uploaded, and also opened some PRs
14:17jgrahamwhimboo: Are you happy with https://hg.mozilla.org/try/rev/d0b20c61afbb38b965f53f37c9e5b22435c8fa2a ?
14:25whimboojgraham: that's my proposed solution from yesterday. So why does it work now? i thought we don't install dependencies
14:25jgrahamwhimboo: I have no idea why it works
14:25jgrahamBut look at all that green
14:25whimboothat would exactly be what we need, yes
14:26jgrahamhttps://treeherder.mozilla.org/#/jobs?repo=try&revision=2a2a0673e19d3eb27717b3fe536a3c733e50d48f <- well all that green
14:26jgrahamwhimboo: OK, if I r=whimboo that commit then?
14:26jgrahamI want to reland this wpt update asap
14:26whimbooi would give it a r+ yes
14:27jgrahamOK, thanks. Mind if I skip reviewboard since I have to push the wpt update directly anyway?
14:27marcojgraham: thanks
14:27marcojgraham: there&#39;s a linting issue at https://github.com/marco-c/firefox-code-coverage/pull/2/files#diff-3379db5a7ed63c1b249162c06051bf2fR128
14:28padenothi #ateam, I have a crastest that needs a pref to be set to run properly, but it&#39;s a different pref in e10s and in non-e10s
14:28marcojgraham: maybe you can fix it by wrapping &quot;args.branch is None&quot; and &quot;args.commit is None&quot; in parentheses
14:28padenothow can I add my test properly ?
14:29whimboojgraham: i made a comment ont he bug
14:29whimboojgraham: i dont know if/how others review those changes before you push
14:30jgrahamwhimboo: A lot of the branch is a=testonly (the mechanical update stuff). A few parts have specific review
14:30jgrahamwhimboo: Thanks!
14:30whimboonp
14:30jgrahammarco: Oh, interesting. That seems like a bug in the lint, perhaps? But I&#39;ll find a workaround.
14:32marcojgraham: it&#39;s strange indeed, https://travis-ci.org/marco-c/firefox-code-coverage/builds/212133103#L229
14:33dminorjmaher: do you know offhand if what padenot wants to do is possible?
14:51jgrahammarco: Actually a subtle bug in the code
14:51jgrahammarco: I think != is higher priority than is
14:51marcoah!
14:52jgrahamSo it was a is (None != b) is None
14:53jgrahamMakes a change from flake8 complaining about the number of blank lines
14:53jgraham:)
14:55davehuntekyle: thanks again for the ActiveData work :)
14:56ekyledavehunt: you are welcome. Next week I will go over it one more time to ensure everything going in.
14:57ekyledavehunt: you can add to the run_info at any time to record more context in your tests
14:58davehuntekyle: awesome, thanks
15:10AutomatedTesterjgraham: hey, it looks like the change to webdriver-rust regarding sendKeys needs a similar geckodriver update
15:11marcojgraham: can I see the patch that fixed the way the browser is closed in wpt tests?
15:11jmaherpadenot: we will be running in e10s only in ~3 months, in the meantime we need to determine if we are in e10s or not
15:13jmaherpadenot: is there an existing pref or window state that you can check for e10s or ! ?
15:13jgrahamAutomatedTester: Yeah
15:14jgrahammarco: OK, sure, let me find it when I&#39;m not causing bustage on inbound :(
15:16padenotjmaher, I need to get specific at this point, I&#39;m afraid
15:16padenotjmaher, this is the pref that disable the popup blocker
15:16padenotand it has a `sync` variant for e10s it seems
15:17jmaherpadenot: sounds plausible; I just don&#39;t know of prior art to determine this
15:17padenotjmaher, I might just land my test in e10s only at this point
15:18padenotif we&#39;re removing non-e10s soon
15:18jmaherpadenot: that is also doable- the goal is to remove !e10s in mid-june
15:18padenotjmaher, this is very edge-casey as well, and I&#39;ve been spending way too much time on it already
15:19padenotbut I don&#39;t want to land this fix without test
15:22jgrahammarco: So the change I made was somewhat marionette-specific https://hg.mozilla.org/try/diff/43ef6295699f/testing/web-platform/harness/wptrunner/executors/executormarionette.py#l1.13
15:22jgrahamIt causes a clean shutdown using eAttemptQuit rather than eForceQuit
15:22jgrahamI think marionette was updated so I might be able to do that in a nicer way, but idk if it landed
15:22whimboojgraham: huh, you should never call thismethod
15:23whimboowhy you need _request_in_app_shutdown
15:23jgrahamwhimboo: Because, at least at the time, it was the only way to get a clean shutdown
15:23whimboojgraham: there is self.marionette.quit()
15:24whimboojust use it with in_app=True
15:25jgrahamwhimboo: self.instance is None, so that fails
15:25whimbooah i see
15:26whimbooyeah, so once Andreas lands his patch it should not be necessary anymore
15:26jgrahamYEp
15:26jgraham*Yep
15:35janxted: hello! do you know why building with ccache results in near 100% cache misses on every Firefox build nowadays? (looking at `ccache -s`, I see a few worrying things like preprocessor errors, unsupported compiler args, unsupported source language, no input file, etc, but nothing frequent enough to justify all the cache misses)
15:36tedjanx: i do not!
15:36tedif you wind up running configure you will get a bunch of non-cacheable compilations from the configure tests
15:37janxted: aha, and does `./mach build` always run configure?
15:38tedno
15:38tedonly when one of the dependencies change (or if CLOBBER was touched)
15:39janxok thanks (shame, because ccache should be especially useful for clobber builds)
15:43tedyeah
15:43tedoh so
15:43tedit *should* mostly work
15:43tedjust because something clobbers doesn&#39;t mean you won&#39;t get cache hits
15:43tedi just mean that you&#39;ll have a slightly lower hit rate if configure runs because most of the times configure invokes the compiler it&#39;s not cacheable
15:47janxted: hm ok, thanks. But &quot;slightly lower&quot; doesn&#39;t quite explain the hit rates of 0% (direct) and 2.7% (preprocessed) I&#39;m observing
15:48tedno, it does not
15:52jgrahamjanx: I seem to recall getting low hit rates, but I assumed it was just because I didn&#39;t build often enough for ccache to help
15:57janxOk, maybe not everything is broken. I just tried running `./mach build` twice in a row (with a `./mach clobber` in between). First build: &quot;11:42.09 ccache (direct) hit rate: 0.5%; (preprocessed) hit rate: 0.0%; miss rate: 99.5%&quot;, second build: &quot;1:49.14 ccache (direct) hit rate: 96.5%; (preprocessed) hit rate: 1.0%; miss rate: 2.5%&quot;
16:01jgrahammarco: Just got a very useful email from bz lamenting the gaps in wpt revealed by the coverage data :) Pretty happy with that :)
16:05tedjanx: okay, so it&#39;s not *completely* broken
16:05tedjanx: someone was complaining on dev.platform or something recently about how slow rebuilds are if you pull m-c like every few days
16:09tedjanx: i think we talked about sccache and janitor, we should be able to make that work pretty well with a few changes
16:09tedonce i get rust sccache support wrapped up...
16:09janxted: by &quot;a few changes&quot;, you mean the two issues you mentionned about supporting multi-tier cache hits and read-only S3 access?
16:10tedyeah
16:10tedit should be a lot easier to make janitor&#39;s environment match our CI build environment so we can get cache hits
16:12janxted: with the source tree in the same location as buildbot? I remember something like /home/worker/?/src/, while in janitor containers the sources live in /home/user/firefox/
16:12* janx is excited about using sccache in janitor, and wonders how fast builds will be with it
16:13tedjanx: yeah, basically, if you make the source path match the build path from CI (you want taskcluster builds, not buildbot), it should be easy to get cache hits
16:13tedyou probably also need to make it use the same toolchain we use in automation
16:13ted(the stuff in the tooltool manifests in the tree)
16:14janxted: also, after pulling in 2 days of work (125 commits), `./mach clobber && ./mach build` gives &quot;10:10.43 ccache (direct) hit rate: 58.6%; (preprocessed) hit rate: 6.7%; miss rate: 34.8%&quot; (which is still not too bad, but I imagine that we obsolete almost all caches on a weekly basis)
16:16tedyeah
16:16janxted: what toolchain is that? janitor uses clang3.9 and gold, with the goal of switching to lld soon (Firefox support is coming soon I hear, and in padenot&#39;s tests lld seemed a lot faster than even gold)
16:16tedsomeone pointed out that since we do unified compilation, if you change any source file in a directory you won&#39;t get a cache hit for a big chunk of compilation
16:17jgraham(someone was just reporting 4s to link with lld)
16:17tedjanx: https://dxr.mozilla.org/mozilla-central/source/browser/config/tooltool-manifests/linux64/releng.manifest
16:23janxted: thanks! Looks almost exactly like what janitor has, except we have gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) instead of gcc 4.9.4. I believe gcc is used to compile some parts of Servo that don&#39;t support Clang yet? Hopefully most of the code base is compiled with clang, right?
16:24tedjanx: we use gcc for official mozilla builds
16:25janxted: ah :/ do we have any plans to upgrade to clang?
16:26tednothing concrete
16:26tedwhat&#39;s the motivation?
16:30janxted: I just think it&#39;s a nicer / more modern tool for developers, with clearer feedback in errors and warnings notably, but I don&#39;t have better arguments than a hunch
16:30tedah
16:31tedfrom the official build perspective there are several axes: compile times, performance of the resulting builds, C++ feature support
16:36davehuntekyle: is this showing the average duration for each test by job/test? https://activedata.allizom.org/tools/query.html#query_id=On8vmaKH if so, can I get that sorted so longest running tests are at the top?
16:38ekyledavehunt: yes, that looks right. you can do percentiles too: https://activedata.allizom.org/tools/query.html#query_id=SK7k4Hg_
16:39ekyledavehunt: but, sorting is currently a poorly supported feature in ActiveData.
16:40ekyledavehunt: when you get the data into your notebook, be aware there are a few formats; some which might be nicer for you to work with
16:46davehuntekyle: what is the percentile value showing me?
16:46ekyledavehunt: 90% of the tests have run times under ____
16:46davehuntokay, gotcha
16:47davehuntekyle: so it removes the extremes values?
16:47ekyledavehunt: yes, exactly
16:47davehuntsweet!
16:49davehuntekyle: so for sorting it&#39;s best to perform after the query?
16:50ekyledavehunt: yes, sort on the client
17:28stephend|labheya folks
17:28stephend|labsomeone mind emailing me (PGP encrypted or otherwise) the a-team Wi-Fi password?
17:28stephend|labhelping Bob with a phone in the lab
17:28stephend|laband he&#39;s temporarily away, it seems
17:29stephend|labnvm; found it
17:29stephend|lab:-)
18:07bakuanyone working on marionette? I Need to set a pref for any marionette test. How can I do it?
18:07davehuntekyle: how can I exclude the tests without a result.result value and the one FAIL without a date from https://activedata.allizom.org/tools/query.html#query_id=XBn9htzG
18:08ekyledavehunt: looking...
18:13jgrahambaku: What pref? Does it need to be set whenever marionette is used?
18:14bakujgraham: yes. I&#39;m making File.createFromFile() unable to run on the content process except for testing (and file content process)
18:14ekyledavehunt: You are asking for a 2dimensional pivot table of values; the last coordinate in every dimension is &quot;everything else&quot;, and used to ensure you have considered the whole population. You will notice that the missing result.result all have zero counts: this means there is nothing outside your consideration.
18:14ekyledavehunt: use &quot;allowNulls&quot;:false, if you are confident in your query: {&quot;value&quot;:&quot;result.result&quot;,&quot;allowNulls&quot;:false},
18:14bakujgraham: but marionette tests use that method for populating a <input type=&quot;file&quot;/> and that happens in the content process. So, I need, as any other test, to enable this API for marionette.
18:16ekyledavehunt: of course, you can do the same for the time dimension
18:17jgrahambaku: Hmm, ato would know for sure but he is not here. whimboo might be able to help, but I think you might want to set the pref somewhere in https://dxr.mozilla.org/mozilla-central/source/testing/marionette/components/marionette.js so it&#39;s always enabled when marionette is
18:17jgrahamWell when a marionette session starts
18:18davehuntekyle: nice, thanks
18:19jgrahambaku: Ah https://dxr.mozilla.org/mozilla-central/source/testing/marionette/driver.js#390 seems to set some pref already
18:22jgrahamdavehunt: I&#39;m wrtiting some pyunit tests and I want to parametize over the combinations of two variables, but which are somewhat related. One is either {&quot;alwaysMatch&quot;: {&quot;something&quot;: value}} or {&quot;firstMatch&quot;: [{&quot;something&quot;: value}]} and the second is <value>. Is there some easy way of doing this?
18:22jgrahamI guess I could make the first a function that accepts value
18:23davehuntjgraham: these are pytests?
18:24jgrahamUh yeah, pytest
18:24davehuntthere&#39;s a pytest_generate_tests hook that can allow you to generate the values
18:25davehuntlet me try to parse what you&#39;re asking for :)
18:26jgrahamdavehunt: That looks pretty complicated, but maybe it does what I need :)
18:26jgraham(I don&#39;t really understand it yet)
18:26davehuntoh, so you want to run a test with parameters: alwaysMatch, <value>; firstMatch, <value>?
18:26davehuntbut value changes?
18:27davehuntso you have a list of values, but want each of them to be run with both alwaysMatch and firstMatch?
18:27jgrahamdavehunt: Right
18:28davehuntjgraham: the parameterise fixture can be doubled up, first with the alwaysMatch/firstMatch, second with the values.. it then does all combinations
18:28davehuntlet me see if I can find an example
18:29jgrahamdavehunt: Right, that bit I got. I think the bit I was missing was to make the output of the alwaysMatch/firstMatch a function
18:29jgrahamWhich allows me to insert the value in the right place
18:29jgrahamdavehunt: Pretty happy that this is good enough now
18:30jgrahamdavehunt: thanks
18:31davehuntnp
18:58* jgraham enjoyed the &quot;no my machine is faster than your machine&quot; on dev.platform (spolier: they are the same machine)
19:01erahmbc, jmaher: should we be seeing awsy builds in automation now? A quick glance doesn&#39;t show any
19:01bcerahm: they are on m-c nightly builds.
19:01erahmbc: oh but not inbound?
19:01bcI had a hard time finding them until jmaher point them out.
19:02jmahererahm: we had some
19:02bcno, not yet. jmaher and I were talking about that earlier.
19:02jmahererahm: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=awsy (6 down)
19:02erahmjmaher: eesh I&#39;d like to see more frequency :(
19:03erahmwe had every inbound w/ arcus
19:04jmahererahm: it can be adjusted, right now it is nightly
19:04erahmjmaher: ah that makes more sense, I thought it was SETA going haywire
19:05bcerahm: starting slow lets us see how it behaves on lower build volume. Easy to change once we see it in production for a little while.
19:05jmahererahm: next week we will have a few data points, you can also retrigger to see how stable it is ;)
19:06erahmjmaher: yeah have low volume doesn&#39;t help me validate the data
19:06erahmI guess I&#39;ll go a on a retrigger-rampage
19:07jmaher++
19:07ted&quot;Request-URI Too Large&quot;
19:07tedwell, that&#39;s the first time I&#39;ve done *that* to bugzilla
19:07davehuntekyle: http://firefox-test-engineering.readthedocs.io/en/latest/reference/activedata.html
19:12dylanted: what&#39;s the problem?
19:12teddylan: i&#39;m sorta trying to find an old bug that i remember working on but apparently can&#39;t find with search
19:13tedso i did a bug activity for myself for the entire year of 2008, and then tried clicking the &quot;view this as a bug list&quot; or whatever that is
19:13bcThat&#39;s what you get for working on so many things.
19:13tedand that blew up :)
19:13tedi guess it just does buglist.cgi?<all the bug ids>
19:13dylanif it&#39;s really old and public, you might try looking on bugzilla-dev which will search all comments very fast. :-)
19:14tedhah
19:14tedoh, wait, that was serious
19:14tedbugzilla-dev.mo ?
19:14dylanhttps://bugzilla-dev.allizom.org/buglist.cgi?quicksearch=FIXED+comment%3Asomething
19:14dylannote that several of the advanced fields, like dates, will not allow elasticsearch to engage currently (but they&#39;re in the design, just not implemented right now)
19:14tedgotcha
19:15tedvery cool!
19:15tedis there an easy way to do that search but also limit it to &quot;bugs i&#39;ve commented on&quot;?
19:15dylanso if you can remember enough words that would be in the comments or summary, it should be easy/fast to find it
19:15dylanthere should be, but currently the &quot;comment author&quot; field is not indexed, sorry. :(
19:16tedokay, np
19:16tedmy use case is often &quot;i know i engaged with this bug but cannot locate it&quot;
19:16dylanI was stupidly bare-bones with what I index from comments: https://github.com/mozilla-bteam/bmo/blob/development/Bugzilla/Comment.pm#L125-L132
19:17tedk
19:17dylanbut I&#39;ll take this use case into consideration!
19:17tedhow does the query work, if i search comment:&quot;foo bar&quot; is it looking for &quot;foo OR bar&quot; or literally &quot;foo bar&quot; ?
19:17tedthanks!
19:17dylanI think it will do all the words in that specific order
19:18dylanbut it uses normal elastic search tokenization rules
19:18tedi don&#39;t know what those are!
19:18dylan&quot;ignores punctuation and case&quot; is a good yardstick
19:19tedokay
19:20tedaha!
19:20tedclose enough, it got me to a bug that blocked the bug i was thinking of
19:20dylan\o/
19:20dylanhopefully you noticed it was way faster than the production search. :-)
19:21dylan(I&#39;m going to be looking at the log files anyway.)
19:22teddefinitely, thanks!
19:25tedbug 428532 was the bug I couldn&#39;t track down, FWIW
19:25bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=428532 Build Config, normal, nobody, RESOLVED WONTFIX, single compiler invocation for C++ files per dir
20:55whimboobaku|away: hi. we have two places. geckodriver.js and driver.js. We are somewhat in a transition of some prefs. does this pref need a restart?
22:21whimbooAutomatedTester: so the refresh patch is ready to be reviewed
22:22AutomatedTesterawesome
22:22whimbooi will add you for now
22:22whimboocommit messages i will do with the next push
22:22whimboothere are still the debug dump() calls in
22:23whimbooso in case i have to change something its easy to do
22:29whimbooAutomatedTester: so next thing for me will be the modal dialog issue
22:29whimboowhich i will start to work on Monday
22:29whimbooenjoy your weekend!
22:30AutomatedTesteryou too!
22:30AutomatedTestersee you!
18 Mar 2017
No messages
   
Last message: 101 days and 9 hours ago