mozilla :: #ateam

9 Jan 2017
12:41AutomatedTestergoing to lunch
13:51whimbooato: hurray for killing all my close window work from friday myself by running hg up -C central :(
13:52whimboooh wait. looks like it survived due to the awesome session feature of sublime text
14:16atowhimboo: Hah.
14:17atowhimboo: Is this when I suggest git wont let you just overwrite your work?
14:17whimbooato: well, the issue is the -C option which I accidentally put in here
14:18whimbooif you force git to switch it would do the same
14:18atoIMO `git reset --hard` is clearer than `hg up -C`. Theres no implicit way to throw stuff away when pulling in git.
14:19whimbooato: well, it would be like git checkout -f
14:21atoI suppose. Theres no guard for human behaviour alas.
14:22atoThrowing away work is the worst. Ive done that a few times with `git shelve`.
14:27whimbooato: indeed. and never forget to commit actual work
14:27whimboopush more often to review, or a user repo
14:28whimbooato: btw. on which bug did you add the timeouts property to GeckoDriver?
14:28whimbooi would like to do it the same way for a property to get the window handles
14:33jgrahamTomcat|sheriffduty: Will 16:00 CET be OK for an autoclassification meeting?
14:34atowhimboo: Instead of leaving work uncommitted in my repo, say over a weekend, I now typically check out a branch with the bug name and make commit with a "tmp" message. Then on Monday I will `git reset --soft 'HEAD^'`.
14:35Tomcat|sheriffdutyjgraham: thats in 25 minutes right ?
14:35jgrahamTomcat|sheriffduty: Yeah. I sent an invitation out last week, I thought, but perhaps it didn't work
14:35whimbooato: yeah. i just missed to do it on Friday and forgot about today
14:36atowhimboo: https://hg.mozilla.org/releases/mozilla-aurora/rev/a5446a3e7e4c#l1.140
14:36Tomcat|sheriffdutyoh there it is, missed it due to holiday here, but yes the time work
14:36whimbooato: oh it already landed! thanks
15:00whimbooato: are you up to moving property definitions to the top of the GeckoDriver class?
15:00jgrahamTomcat|mtg: Join LON 410?
15:01whimboothe mixture of properties, helper methods and webdriver commands is not ideally imho
15:01Tomcat|mtgyeah
15:02atowhimboo: I dont have an exact idea about their placement.
15:03atowhimboo: Were slowly moving towards better code organisation. testing/marionette/driver.js was a bigger mess three years ago, I assure you.
15:04atowhimboo: I have some rough future plan to make the distinction between WebDriver command implementations somewhat more decoupled from helper functions and session state. The rewriting of the capabilities parsing is one step in this direction, where all session state now lives in testing/marionette/session.js.
15:04whimbooato: heh, thankfully I haven't looked into it earlier? ;)
15:06atowhimboo: To shed some more light into this: Now that we have namespacing in the Marionette protocol (addon:*, cookie:*, i11n:*) its not far-fetched that we could implement the command handlers for these in separate modules.
15:06atowhimboo: You plug in your module and it auto-registers the handlers it implements, or something.
15:06whimbooato: ++ same for the offlcial webdriver commands?
15:07whimboowhich might be in webdriver.js or similar
15:07atowhimboo: Potentially I havent given it much thought yet.
15:08atowhimboo: Yeah, possibly that might work. Those commands we do implement which arent WebDriver conforming could I guess live outside of that.
15:10Tomcat|mtgjgraham: https://treeherder-prototype.herokuapp.com/#/jobs?repo=mozilla-inbound&selectedJob=39537611
15:38Tomcat|mtgjgraham: bug https://bugzilla.mozilla.org/show_bug.cgi?id=1117583
15:38bugbotBug 1117583: Treeherder, normal, wkocher, VERIFIED FIXED, Create a minimal UI that sheriffs can use to file bugs for new intermittent failures more quickly
15:42atomaja_zf: Are you subscribed to the public-browser-tools-testing@ mailing list?
15:42maja_zfato: nope, never heard of it. it's a mozilla list?
15:43atomaja_zf: Its the WebDriver WG list and theres some discussion going on there about actions which is probably relevant to you.
15:43atomaja_zf: https://lists.w3.org/Archives/Public/
15:43atomaja_zf: https://lists.w3.org/Archives/Public/public-browser-tools-testing/2017JanMar/0004.html
15:46maja_zfthanks, subscribed
15:47jgrahamIt's a trap!
15:47maja_zfhaha
15:56mcoteemceeaich: you still going to do your talk today at the weekly meeting?
16:09emceeaichYes I need to update the wiki
16:19jmahergbrown: oh, landing the l32 tests:) did you make changes to the packages, or is this a fingers crossed thing?
16:22gbrownjmaher: fingers crossed + I'm breaking the patch down into a few components, so if it fails again I should have a clearer idea of the cause
16:23jmaheroh cool
16:45whimboooh, mozreview got an update.... all so big now
16:46mcotesome of it is smaller :) (the commtis table is collapsed by default)
16:48jgrahamThat looks pretty strange.
16:48jgrahamThere's a table with a heading, and then something that doesn't go with the headings and then some columns that do go with the headings
16:49jgrahamand then a gap and then a different table, and then no gap and then the toolbar that looks like it's supposed to be at the top of the screen
16:49jgrahamAm I seeing the right things?
16:50jgrahamAnd then another heading that's a repeat of the thing in the first table
16:51atoIm not sure this visual change is an improvement.
16:52jgrahamAnd then some more metadata, then some hg commands that aren't relevant to me, then a commit message, then I run out of screen space
16:53jgrahamIt seems like not a lot of useful stuff "above the fold" and what is there not in the most logical places
16:54maja_zfoh my, mozreview looks very different since this morning
16:54atoSo, the font size for everything in the UI is massive on my non-retina screen, and the font in the diff viewer is tiny.
16:54jgrahamAlso, the difference between "Review" and "Reviews" is apparently critical and totally non-obvious
16:54atoAnd theres at least three or four different fonts in use.
16:54atoAnd none of the UI bugs Ive filed on mozreview have been addressed. (Regarding contrast, font sizes, link colouring)
16:55jgrahamAnd with a try job, there is a bad loading experience
16:55jgraham(see e.g. https://reviewboard.mozilla.org/r/102348/ where the "some jobs failed on try" row first overflows then resizes during load)
16:56atoWhats up with All The Capitalisation For Everything?
16:56atoThats such an Americanism.
16:56atoThe Always Show All Comments preference that is always present is broken too.
16:57atojgraham: Can you look at the remaining issue here? https://reviewboard.mozilla.org/r/101878/diff/1#index_header
16:57maja_zfyou guys remind me of statler and waldorf
16:57atojgraham: (If you can manage to.)
16:58whimbooato: totally agree re degration of the usability
16:58Callekato++
16:58Callekato: double plus on all those comments
16:59Callekato: I was bringing it up with mcote in #mozreview who just pointed me here
16:59mcoteCallek: I didn't point you here
16:59mcoteI was pointing the mozreview devs here
16:59Callekmcote: well, you pointed me at other discussion
16:59Callek:-)
16:59Callekbut fair
16:59Callek:-)
16:59davidwalshmcote and a few others thought the table would be best served above the "content" area
17:00mcoteno one seems to object to that part at least, I don't think
17:00Callekdavidwalsh: I don't mind the review table and such being higher, but the humungous font eliminates any usefulness of that
17:01jgrahamI think the commit table should be under the heading telling you about the curren tcommit
17:01davidwalshI'm looking at the font-size now...what item(s) specifically? The font-sizes were super small for me and I have to zoom a bunch; I wouldn't consider any of the font sizes outrageous
17:01Callekdavidwalsh: I admittedly rarely need the "Information" stuff, that used to be sidebarlike, and is now below "table" of commits, but above any potential diff of commits
17:01davidwalshjgraham: I agree but others didn't fwiw
17:01jgrahamI' trying to rearrange things in the DOM inspector now to show what I would prefer within the constraints of what that allows
17:01Callekbut its presence there, especially with shortened command lines in the don't-look-like-textboxes textboxes is confusing
17:02Callekdavidwalsh: did you see my screenshots in #mozreview
17:02whimbooato: so close() and closeChromeWindow() both work synchronous now. Last step is to add new tests
17:02Callekdavidwalsh: old (1): https://irccloud.mozilla.com/file/ag1jtxEn/image.png
17:02Callekdavidwalsh: old (2): https://irccloud.mozilla.com/file/L2krctlf/image.png
17:03Callekdavidwalsh: old (3): https://irccloud.mozilla.com/file/pOwQoVHT/image.png
17:03Callekdavidwalsh: new (1): https://irccloud.mozilla.com/file/p4rzHBx6/image.png
17:03Callekdavidwalsh: new (2): https://irccloud.mozilla.com/file/53fHAC7w/image.png
17:03Callekdavidwalsh: new (3): https://irccloud.mozilla.com/file/6DAZvDpa/image.png
17:04Callekdavidwalsh: its basically much worse when looking at the whole commit
17:04Callek(rather than an individual changeset)
17:06Callekdavidwalsh: also the "header" with "Download Diff" "Autoland" etc, I would rather be above the table, since its explicitly a header.... especially in new UI where the commit table is not as distinguished from the rest of UI
17:06davidwalshCallek: I can bump down the font-size without issue; the flip side is the number of people who've commented that they have to squint to see things, and end up having to zoom their browsers in so they can read stuff without hurting their eyes
17:06davidwalshCallek: That was going to be the "next step"; i.e. moving the buttons to the top
17:06Callekdavidwalsh: solution (note: I didn't read the source to see) don't define font in px, define it in pt/em stuff
17:07davidwalshCallek: IMO, which others mentioned they didn't want, was that the content area should be above the table, thus moving those action buttons above it
17:07Callekdavidwalsh: the BIGGEST piece, is for all fonts to be relative to each other, in a reasonable manner
17:08jgrahamdavidwalsh, mcote: http://pasteboard.co/k3VXJyMkh.png is what 5 minutes and the DOM inspector allowed (just (re)moving content, not fixing fonts, colors, etc.)
17:08Callekdavidwalsh: so that if people have to squint, increasing the mozreview font size is a reasonable solution, as is decreasing it... but default should be endeavored to be most-useable by most people
17:09Callekdavidwalsh: as it stands, if I decrease, I can't read the diff well, but if I increase its "even worse" where its big
17:09jgrahamI guess I would also make the vcs things view on click, like in GitHub
17:09jgraham(and add git for git cinnabar users ofc)
17:10atoRegarding the font sizes, I think the main problem is that theyre just disproportionate to eachother.
17:10atoNow the sans-serif fonts are massive compared to the font size in the diff viewer. Apart from the inline issues which are also tiny.
17:11atohttps://irccloud.mozilla.com/file/LzfFSNCN/screenshot-2017-01-09-171101.png
17:11Callekagreed, I'd like them to be reflective of my Firefox/system defaults, at the same time proportionate to each other. So if I have to increase the font size to read the diff, fine it works -- if I have to decrease it because its too big, fine everything works. but if I have to increase and decrease to use mozreview, I'm likely to stop using mozreview
17:11jgrahamIt's really unclear why "Always Show All Commits" is in giant bold text, whereas the commit message is relatively tiny text and the hg commands are giant text, and so on
17:12Callekjgraham: exactly, the new UI (with regard to font sizes and boldness/borders/etc) draws attention TO the wrong things, and away from others
17:12atoIm not sure if we need the line numbers to be that big, for example.
17:12atoCallek, jgraham: Indeed.
17:12Callekat the same time making it feel like its the perfect size in the things that matter (diff/commentary) to me
17:15Callekdavidwalsh: basically, to me, this feels like you are heading strongly in the right direction, but this feels like you are building a bigger, newer, better house, but scheduled us to move in before construction is done. -- as such, I think I am advocating for a rollback of the UI change, until there can be a bit more polish in (my percieved) useability ready
17:15Callekto land
17:15Callekdavidwalsh: make sense (I hope I'm not exuding too much stop energy, or diminishing the value you felt on your work here. I am truely happy that mozreview is getting UX love)
17:16davidwalshCallek: I expected this
17:16mcotewe did vet this design with some users fwiw
17:17Callekmcote: to be clear, I'm still concerned at the fact that a bunch of those reviews on that page, are still having issues loading diffs....
17:17Calleks/that page/my linked reviewboard example/
17:17mcotethat is concerning (unrelated but concerning nonetheless)
17:17davidwalshCallek: I think I'm trying to apply some "polish" that would work on a "marketing" site that don't work with RB users, apparently
17:17Callekyea --- doubtful its even remotely related, but wanted to point it out
17:17jgrahamYes, I'm very happy we are trying to make the rb ux better
17:18davidwalshre: font size, I've had a bunch of people tell me it's too small, then when I change it, I'm told too big
17:18jgrahamI just think there are some issues with this particular set of changes
17:18Callekdavidwalsh: if you were applying polish you expect to be good on marketing sites, then yes I'd agree it can't be equally applied to RB at mozilla.
17:19jgraham(fwiw I'm not exactly concerned that the fonts are "too big" but that the wrong things are big/small/grey/black)
17:19davidwalshThe root issue with font-size probably is that I went from Verdana to Arial, and 11px to 14px
17:19Callekdavidwalsh: the biggest piece about font size, is as ato said, relative font size, and emphasis of size as compared to each other.
17:19davidwalsh11px Verdana is absolutely unreadable to me and using MozReview like this would give me hedaches
17:19davidwalshCallek: I agree -- I'll work to fix that
17:20Callekdavidwalsh: and as I said, "11px" is absolutely a bad model, use em or pt on the web (imo)
17:20davidwalshBearing in mind that RB uses percentages for font updates, so most of this wasn't caused by me changing different stuff
17:20jgraham(the font in the issue and diff viewers for example is still pretty tiny, and that's the most important stuff on the entire page)
17:20Callekdavidwalsh: as px doesn't account for DPI or overall screen resolution, but basing everything on % or em/pt works better
17:20atodavidwalsh: Verdana to Arial/Helvetica is probably a good move.
17:20atoAlso what Callek says.
17:20jgrahamCallek: CSS px is defined as 1/72 inch
17:21Callek++ (Verdana is bad for the web, due to its enlarged sizing compared to other fonts of the same class of fonts -- since Verdana is also not available on all OSs)
17:21davidwalshjgraham: ato: Callek: In devtools I changed the font to 0.8em; maybe that's more to your liking overall?
17:21davidwalshpx is used elsewhere for specific titles but I can change those
17:21Callekjgraham: well, CSS px is still not perfectly a PX, given difficulty in properly specifying DPI on some OS's/Monitor types
17:21davidwalshI'd like to have a good base size people agree on before making overwhelming changes that could just infuriate people again
17:22jgraham(silly question: why don't we just use Fira for the font?)
17:23davidwalshjgraham: I did that, showed it to some people, and they didn't like it
17:23Callekjgraham: davidwalsh: either way, I'd argue px vs pt/em is not as important as proper relative sizing and consistent font-family designations. Comparatively Verdana is not bad in and of itself, as long as specified font-families along with it are very similar in size (and weight for that matter)
17:24CallekI'm also a fan of keeping the diff a monospace unweighted font, and the line-numbers "no bigger" than the font used for diff (but also no less than 70% size)
17:24davidwalshI'm happy to implement relative sizing, even ecstatic to do so, but it would save us all a lot of time if we could agree on a size now
17:25davidwalshI always zoom MozReview like 4x because the original size gives me headaches
17:25davidwalshThe line numbers look bigger because of the base font
17:25davidwalshSo we adjust the base font and the line numbers will change
17:25Callekdavidwalsh: well thats the trick, relative sizing doesn't need an agreed upon size, since if its all relative to one another, you can increase/decrease easily as a user -- also if you relative-size everything properly in the CSS you can change the master value(s) easily without needing to change everything
17:25jgraham(alternate point of view: just use "serif", "sans-serif", "monospace" and the font names so that people can use their system defaults)
17:26jgraham(anyway I don't care too much about the specific choice of fonts, I care more about the information design and the relative emphasis given to different things in the UI)
17:26Callekdavidwalsh: CSS variables could even make the ability to tweak this far easier, if we have a lower-end mozreview base UserAgent that supports in all cases...
17:26atojgraham: Does upgrading geckodriver on tooltool require a commit in m-c, or is in out of tree?
17:26Callekjgraham++
17:26atojgraham: Im wondering how I can land these changes without breaking the Wd tests.
17:27jgrahamato: Requires a commit in m-c
17:27jgrahamI forgot to do that after the last update
17:27jgraham:/
17:27atojgraham: Im not sure, but I hope upgrading it does not break Wd.
17:27Callekato: you can upload a new binary to tooltool, but if tooltool is used to fetch, you need to land a change to the used tooltool manifest
17:27jgrahamAlso callek is the expert :)
17:27atoCallek: Right, thats great actually in this case.
17:28* Callek isn;t sure what GeckoDriver is used for, or what tests use it, or where the manifest is, but I know the fundamentals quite well
17:29davidwalshCallek: ReviewBoard's font-sizing is all over the board -- sometimes they use px, sometimes they use %, other times em's
17:29Callekdavidwalsh: and thats likely a LARGE part of the issue here
17:29Callekdavidwalsh: basically mixing px em and % is probably worse, because its pretty damn hard to decipher what *relative* meaning anything has
17:30davidwalshCallek: Right, so what I want to accomplish this moment is a good base size, get that merged now to make people happ*ier*, then in the future I can go into RB's and swap all their font units around
17:30Callekdavidwalsh: I endeavor for internal consistency and relative emphasis, much more than I endeavor for idealistic choices among many options.
17:30davidwalshI want to solve the *right* now
17:30davidwalsh... .*right now*
17:30davidwalshSo that people don't want to revert all of the changes
17:31davidwalshTo me, a base size of 0.8em seems to roughly match the previous font-sizes
17:31Callekdavidwalsh: well &quot;a good base size&quot; is dependant on what you consider base, and what/how things are relative to that base. So if we have a smaller base for <stuff> but other things that are similarly sized don&#39;t change, then we&#39;re not really much better off, because those things would be bigger. or if we have things at the similar size of the new base, then
17:31Callekthings that should be de-emphasized would conflict with things that should be emphasized, ect
17:32Callekdavidwalsh: its less about the specific font size, and more about relative emphasis and what is grabbing my eye
17:32Callekto be fair
17:33Callekif the font sizing on many things is ~ as large as the important things, then thats whats going to drive me in a bad way. Similarly if we decrease the main-page font size, but that also drives the diff font size down, I may end up needing to increase the font size anyway, to undo what you just did and that could cause me to have the same issues I do now
17:33Callekdavidwalsh: note of course, that `0.8em` could be `11px` to your screen, and `8px` to my screen (or `16px` to my screen)
17:35Callekdavidwalsh: if we&#39;re measuring in em/etc I&#39;ve found the &quot;proper&quot; sizing is `100%` or `1em` as a base, there are of course many web designers (many of which have great eyesight) who design for a target of 0.8em/80%/10px/11px as a primary font
17:35davidwalshI literally have nowhere to go from here except &quot;change the font size&quot;; I realize that fonts should be relative -- what I&#39;m saying is base RB, the project MozReview is built on, has font sizing all over the map, so if we pick a base font-size that I can apply to the <body> that we like, many of the font-size problems can be eased in the short term
17:35Callekbut the idea here, is that the proper sizing is all relative, so that if I find the content on your site at 1em to be too big, I can easily reduce that to suit my needs, or if too small I can increase it, end result is I&#39;m happy :-)
17:36Callekdavidwalsh: well, my point is, prior to this landing the relative sizings were pretty sane (give or take some small concerns) post your landing the relative sizings are pretty insane (imo)
17:36Callekso even if base RB has sizings all over the map, something in how these sizing specifications are used changed in such a way to make it much worse.
17:37Calleke.g. % sizing cascades changed and thus things that really should have cascaded down to 70% may now be 95%, etc
17:38vkatscould I ask here a webdriver spec related question? As many people involved are here?
17:39davidwalshCallek: I guess I&#39;m asking you to humor me: In a perfect world, what size and value would you like the font to be?
17:39Callekdavidwalsh: as one concrete example see jgraham&#39;s comment at <now().hour>:11
17:40Callekdavidwalsh: to humor you, lets say, I like the diff view of this (or even ~95% of this) https://irccloud.mozilla.com/file/jCB8g6Ef/image.png
17:40Callekdavidwalsh: that is the &quot;now&quot; size
17:40davidwalshI agree with jgraham&#39;s comment and I&#39;m happy to change it
17:40Callekdavidwalsh: line numbers can be shrunk a bit, but current line number sizing doesn&#39;t bother me
17:41Callekdavidwalsh: everything (except heading) in <link> is too big, and the smallest (important) content here should be ~2px bigger than the used diff text -- with other pieces sized relatively) https://irccloud.mozilla.com/file/my4HXczK/image.png
17:44Callekdavidwalsh: I also like some horizontal space on the commit table, and some visible boarders too... if that helps as some additional concrete information...
17:45Callekdavidwalsh: I&#39;ll be the first to admit, I&#39;m not a UX designer, and suck at UX designs. But I&#39;ve learned to try and give use-cases and concerns in as little of a bikesheddy way as possible, since I&#39;m also not the only human using a design and I&#39;m also not the best at weighing the right way to solve a use case (even if I *think* I know what I&#39;d want, the use
17:45Callekcase could be met other ways, and sometimes those other ways make OTHER usecases that I don&#39;t care about, better)
17:46Callekdavidwalsh: so in this I&#39;m actively trying to stay slightly abstract so I can keep what *I* think would work for me outside of what *may* work for me and many others.
17:46* Callek also doesn&#39;t even grok as well the difference between serif and sans-serif fonts, though I&#39;ve read many people argue for/against each one in a variety of cases... Only think I know is you shouldn&#39;t mix them both in the same type of content.
17:50Callekdavidwalsh: so, basically -- the end state desire for me, in this redesign work, is &quot;Lets avoid taking any big steps back, even if they are to re-align us on the right path forward..&quot; if fixing the path means we step back a few steps, we probably need to run back forward and see if we can have a bigger path fix first&quot; (to overuse the metaphor)
17:51Callekdavidwalsh: that is a desire as long as we&#39;re still expecting many of our company to use mozreview and still have strong goals of moving more people over to it. Since if we&#39;re taking big steps backward, we&#39;ll likely lose a lot of forward momentum and ground with people who are already adverse to change in process (as in, they will switch back to what they
17:51Callekwere comfortable with, and those who haven&#39;t used it yet will have further restraints in moving to it)
17:58globekyle: hai
17:58mcoteekyle: do you know you&#39;re on vidyo? :)
17:58davidwalshCallek: re: &quot;the end state&quot;, I&#39;m trying to get from you the desired &quot;beginning state&quot; so we can get to the end state; I&#39;m asking you what font size youd would like
17:59davidwalshCallek: In no way am I refuting or arguing *anything*; I&#39;m asking you specifically what you&#39;d like the font size to be
17:59jgrahamdavidwalsh, mcote: FWIW a little more moving stuff around http://pasteboard.co/k4ORf8U4p.png
17:59jgrahamAnd some more visual cleanup
17:59Callekdavidwalsh: the beginning state to me, is the state mozreview was in prior to your patch landing :-)
18:00jmaherwhoa party in toronto
18:00* ted wonders how bad the weather in TO is currently
18:00davidwalshSo 11px Verdana, got it
18:00Callekdavidwalsh: and that font size I found overall acceptable. the path between that beginning state and the end state should avoid major steps backward imo -)
18:00Callekdavidwalsh: noteworthy, I&#39;m on linux and no Verdana font installed....
18:00Callekdavidwalsh: so I got a fallback
18:00Callek(Verdana is also larger than most other fonts on the web)
18:02Callekdavidwalsh: so `fc-list | grep -i Verda` has no entries
18:04davidwalshI will happily implement any <body> font-size and font-family I&#39;m asked to, and adjust from there
18:05mcoteted: getting warmer actually, going to be 6 celsius on thursday
18:05tedwhee
18:05tedsupposed to warm up here thursday as well
18:05jmaheryeah, likewise here, had 11F this morning, was really hoping for 1F
18:06globted: i went from ~35C to -11C. it&#39;s cold here
18:06jmaherglob: ack! welcome to Toronto!
18:06tedglob: oof
18:06tedglob: unrelated, but i got a steam link for christmas, it&#39;s pretty nice
18:06jmahersteam link?!?
18:07tedjmaher: it&#39;s a little device that does Steam in-home streaming
18:07globted: smacleod has one; i hear a lot of good things
18:07tedso you run games on another computer and stream them to it
18:07jmaheroh
18:07* jmaher was thinking like a steam iron or something
18:07smacleodsteam link is awesome
18:07tedhumorously it&#39;ll just stream your whole desktop so you can alt+tab out of steam on windows and stream whatever :)
18:08tedsmacleod: i&#39;m impressed at how well it works
18:08smacleodted: Ya. I&#39;m really happy with the controller support too. I use it to play 4 player games with controllers mostly
18:09tedcool
18:09tedi liked that they call out Xbox One controller support in a product bullet point
18:09tedi wrote that kernel patch :)
18:09smacleodha, nice :)
18:10tedi bought a steam controller last week, but when i tried to use it it asked to install a firmware update and then got stuck in a loop :-(
18:11smacleodted: I had that happen once. Force restart it, and plug it in to do the firmware update
18:11tedah
18:12jmahergbrown: looks like your first change for ubuntu 12.04 worked well
18:12gbrownjmaher: so far, so good. will push the next patch soon.
18:13atoFor the record, quite a few of us cant follow up on the newsgroup.
18:14wlach|mtgato: yes, and we should fix that
18:14atoekyle: Works
18:15gpsvidyo inception
18:18armenzg_mtgthere&#39;s still echo
18:18jmaherif you joined in the last 2 minutes, please mute
18:18janxMTV 269 please mute
18:19tedit&#39;s either MTV or TOR
18:19janxA-Wing
18:19ahalMTV and TOR
18:19bctor and mtv should mute
18:19armenzg_mtgjgriffin: I think you can mute people
18:19jmaherkick them out?
18:19tedbetter
18:19jmaheremceeaich: thanks! I have been stuck in that position before
18:20emceeaichthat&#39;s odd, the conference rooms I thought were set up so that they didn&#39;t have to mute
18:20jgriffinemceeaich: I muted you, if you want to be unmuted let me know
18:21jgriffinemceeaich: yeah generally they don&#39;t need that
18:22janxtrue, professional vidioconf equipment should not echo like that, perhaps sound and microphone systems are not properly integrated
18:23jgraham(Seems like it might be possible to write a more efficient ETL pipeline vs one in Python, if the cost is significant)
18:24jgraham(that was not me volunteering btw :p)
18:28Callekdavidwalsh: I hope my screenshots/comments around 12:40 actually help -- and of course noting that my system doesn&#39;t actually have Verdana so while it may have been ok on my system with whatever the fallback was after Verdana, it may not have been ok on a system with Verdana, I can&#39;t be sure
18:29Callekdavidwalsh: also, note those screenshots are my *whole* screen, on a gen3 X1 carbon, so I purposely make my screen bigger (smaller aspect ratio) to suit my eyes, which require bigger fonts than some. But this way (overall aspect ratio changed) I get better readability in my UI fonts and not just website fonts
18:52ahalekyle: nice presentation!
18:52wlach|mtgekyle: yeah, thanks for presenting!
18:52jmaherekyle: very interesting
18:53jmaherekyle: possibly we should be questioning each type of data, vs the entire data solution
18:53jmaheri.e. code coverage - where should this live
18:54ahalekyle: fwiw, I think there&#39;s a lot of value in active data that we aren&#39;t making use of.. I&#39;d be curious to expriment with that redash server wlach was talking about
18:55ahalI&#39;ll echo others in that difficulty in building the query has kept me from using it more often
18:55ahalbut that&#39;s also a function of laziness.. we could all become experts in it if we were motivated enough to
18:56jmaherahal|lunch: very true
19:00janxmcote: Hi Mark! Could you please send me a calendar invite for the Commit Pipeline meeting if there is one?
19:01janxmcote: Also, does it make sense to add a Janitor component to it? (for: writing code, creating/reworking/publishing commits, assisting code reviews?)
19:01jmahergbrown: nice, I suspect this will be the patch that is most problematic
19:05wlachjgraham: could we reuse anything in wpt for a cross-platform performance test harness?
19:07wlachjgraham: there&#39;s some interest in getting some benchmarks set up for quantum, initial thought was talos, but on further thought I&#39;m wondering if something where we could also measure servo might make more sense
19:07jmaherwlach: ?
19:07wlachjmaher: just thinking aloud
19:08jmaherok, I didn&#39;t know if you had heard more from others on the email thread
19:09wlachjmaher: yeah I was just thinking about it more after we discussed things
19:09wlachtalos only covering m-c is a bit of an annoying limitation
19:10jmahers/m-c/Firefox/ ?
19:10wlachyeah
19:10jmahertrue
19:11jmaherand we do have wpt on all desktop platforms
19:22ekylejmaher: one benefit of big/hot is that the effort supporting ActiveData servers is amortized over multiple data sources. If we look at each type of data, we may loose this benefit. But, when moving to Telemetry we will have to consider one type of data at a time because Telemetry has a stricter typing infrastructure.
19:26jmaherekyle: so if we have test data from buildbot/taskcluster for a testfile as well as coverage data, we haven&#39;t been using the data to cross reference, instead we use code coverage for code coverage
19:26ekyleahal: thanks for your kind words. I certainly beleive there is a lot more that can be done with ActiveData, and I think we know what the barriers are (hard to query, not fast enough on specific queries, etc), now he problem is if they can be solved
19:27ekylejmaher: the benefit of activedata is merging all the separate coverage runs into a single coherent whole, and responding to queries fast.
19:29jmaherekyle: yes- would telemetry be able to do that?
19:29ekylejmaher: (for just showing codecoverage). On the subject of cross referencing, you are right we have not explored what&#39;s possible.
19:29jmaherI am trying to find areas where it might not work out
19:30ekylejmaher: telemetry can do anything, the question is how much human effort is required to achieve what query response speed.
19:30jmaherso we do have a lot of desire to take a set of code coverage files and create a single report
19:30jmaherekyle: heh, true- so can microsoft access ;)
19:31jmaherekyle: if we take the list of data we have inside of active data, the historical/current uses, and possible some future uses (speculative), we might be able ot outline this better
19:31ekylejmaher: don&#39;t know MS Access: It is awesome! (well, except for its deficiencies) :)
19:35ekylejmaher: I think the list we have now for code coverage use cases is keeping us busy. The outline for codecoverage, from my perspective, is to make all data available quickly; which is independent of what we want to do with it. It is a strategy that can be reused for other data, and I believe our technology is capable of doing this.
19:35mcotejanx: yes, didn&#39;t I send it already?
19:36mcotehuh
19:36mcoteit didn&#39;t stick I guess
19:36jmaherekyle: I don&#39;t think we need speed for code coverage, unless we start requiring gecko decision tasks to make intelligent decisions
19:36mcotejanx: there we go :)
19:37jmaherekyle: but I suspect we can achieve that with finding patterns or creating tags that can be used as inputs
19:42ekylejgraham: I missed the wording of a good point you made, something along the lines of &quot;queries for specific data is too slow&quot;. May you repeat that for me? I want to record the concerns at the top of the document.
20:33jmahergps: will you have time to look at bug 1291926 today or can you recommend someone else if you don&#39;t have time?
20:33bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1291926 Mercurial: hg.mozilla.org, normal, nobody, NEW , Intermittent Windows builds failing with abort: stream ended unexpectedly (got 131914 bytes, expected 1630418948)
20:48gpsjmaher: if there is a needinfo on me, yes
20:49jmaheryes, there is a ni for you- even if you can get to it tomorrow that is fine
20:49gpsi didn&#39;t triage email last week and today i&#39;m working through the backlog :/
20:50* jmaher leaves gps alone to manage his own backlog :)
20:59RyanVMgbrown: I&#39;m just curious about https://hg.mozilla.org/integration/mozilla-inbound/rev/4bea6ef3d9de
20:59RyanVMwere they as flaky on TC as they were on BB?
21:00gbrownRyanVM: hard to compare very well, but I was seeing some intermittent timeouts
21:01RyanVMon BB there are chunks that are permafailing
21:04gbrownjust need a reconfig to end that, I think
21:04jmahergbrown: I see more landings, did the 16.04 image land successfully and stay green?
21:04gbrownyes!
21:04gbrownI have no idea why the previous attempt failed
21:05jmaherthat is odd, possibly we will be done :)
21:11jmahergbrown: what is the bug # for the mach file-info work?
21:12gbrownjmaher: do you mean bug 1324470 (&quot;mach test-info&quot;) ?
21:12bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1324470 General, normal, gbrown, NEW , Add mach command to access historical test results
21:12jmaheroh yes, test-info
21:12jmahersorry
21:14jmaherthanks gbrown
21:15gbrownany time
21:19RyanVMgbrown: ah well, I can experiment on Try after that merges around
21:22jmahergbrown: wlach: I posted info about stockwell for January: https://wordpress.com/post/elvis314.wordpress.com/1400; I will make a dev platform post referencing this probably tomorrow- but if you see anything I should change in my blog post, please let me know
21:23RyanVMhttps://elvis314.wordpress.com/2017/01/09/project-stockwell-january-2016/
21:24gbrownexcellent - will have a look right away
21:24jmaheroh thanks RyanVM, I am bad with wordpress
21:27gbrownjmaher: lgtm - thanks!
21:27jmahergbrown: great, thanks for taking a quick look
21:27wlachjmaher: looks great, thanks for posting!
21:28wlachjmaher: I&#39;m trying to sketch out a plan for bug 1322433 right now
21:28bugbotBug https://bugzilla.mozilla.org/show_bug.cgi?id=1322433 General, normal, wlachance, NEW , Make it easier to retrigger a job with failing test with extra logging and debugging options
21:29jmaherwlach: nice- I don&#39;t think that will be an easy bug, but it will open the door to a lot of stuff
21:30wlachjmaher: yeah