[09:01:21] <DaveMethvin> yay
[09:01:27] <DaveMethvin> give me just a couple of minutes
[09:01:33] <DaveMethvin> in the meantime, sound off!
[09:02:42] <gibson042> Oi!
[09:03:20] <DaveMethvin> m_gol gnarf  whoever else
[09:03:26] <DaveMethvin> gotta make an agenda
[09:03:32] <gnarf> yo
[09:04:58] <DaveMethvin> ok ... light turnout today
[09:05:06] <DaveMethvin> but i really love the people who are here
[09:05:10] <DaveMethvin> quality not quantity
[09:05:30] <gnarf> heh
[09:05:35] <m_gol> present
[09:05:51] <gnarf> I think there is some discussion going on in https://github.com/jquery/api.jquery.com/pull/530 that more people should weigh in on
[09:05:52] <gnarf> also
[09:05:59] <gnarf> please read my email about the pull request drive
[09:06:01] <gnarf> :)
[09:06:28] <DaveMethvin> i'm glad you're doing that, although my inbox is swollen so much now
[09:07:10] <DaveMethvin> having the CLA checker will help a lot there gnarf, such a pain to have to wait for that
[09:07:33] <gnarf> DaveMethvin: agree - I was thinking that there is another way we could do that
[09:07:35] <DaveMethvin> altho i'd prefer we could just have a click-wrap license above the PR process so we didn't need a separate cla process
[09:07:50] <DaveMethvin> github would need to do that for it to work tho
[09:08:02] <gnarf> Might be something arschmitz and I can look at
[09:08:27] <arschmitz> I heard my name
[09:08:33] <DaveMethvin> i'd just like gh to make a simple change for that
[09:08:37] <gnarf> we have a jquerybot user that could add comments on failed CLA and also add/remove a tag
[09:08:42] <DaveMethvin> the fewer complex processes on our side the better
[09:09:12] <arschmitz> gnarf: scott_gonzalez and i discussed this already
[09:09:12] <DaveMethvin> i think we can get the people who care to agree that a click-wrap license is adequate
[09:09:20] <arschmitz> scott_gonzalez: has a proof of concept already too
[09:09:21] <gnarf> DaveMethvin: have we reached out and ask them yet?
[09:09:31] <DaveMethvin> github? not here
[09:09:35] <DaveMethvin> we just talked about it last week
[09:09:47] <DaveMethvin> in relation to the picture polyfill
[09:09:52] <arschmitz> but it would nice to have it a forced part of the PR process rather then a bot
[09:10:07] <scott_gonzalez> I'm actively working on it.
[09:10:18] <scott_gonzalez> See https://github.com/scottgonzalez/temp-test/pull/4
[09:10:32] <gnarf> scott_gonzalez: cool - I can offer some help on it if needed
[09:11:08] <DaveMethvin> https://github.com/jquery/contribute.jquery.org/issues/95
[09:11:15] <arschmitz> Yeah iv already said im happy to help to
[09:11:28] <DaveMethvin> gibson042: i agree that no space makes the precedence clearer
[09:11:42] <m_gol> i.e. the last comment?
[09:11:47] <DaveMethvin> yeah
[09:12:12] <DaveMethvin> but maybe markelog is right about needing a full grammar for this :)
[09:12:28] <DaveMethvin> jscs should add a parser :)
[09:12:32] <gibson042> heh
[09:12:56] <m_gol> Esprima won't help here ;)
[09:13:07] <DaveMethvin> so are we spacing out everything then? I had some of these doubts when i did that big comment commit a while back
[09:13:19] <gnarf> RE: Support comments, I think we've painted a few bike sheds there now -- We've looked for all the edges...
[09:13:28] <gnarf> Consistency - spaces around everything seems bests
[09:13:46] <gibson042> I agree
[09:13:46] <gnarf> we wouldn't write 9-11 in js, we shouldn't write it in the comment either
[09:13:49] <DaveMethvin> really Android 2.3 would be fine for me since anything < is pretty damn old now
[09:14:15] <DaveMethvin> yeah we'd just write -2 :)
[09:14:44] <gnarf> or +new Date()
[09:15:30] <DaveMethvin> here's a docs one https://github.com/jquery/api.jquery.com/pull/530
[09:16:25] <DaveMethvin> i don't really want two unrelated things on the same symbol, that seems bad
[09:16:38] <gnarf> DaveMethvin: .ready ?
[09:16:46] <DaveMethvin> jQuery.ready
[09:17:40] <DaveMethvin> the reason we created .holdReady was to keep from documenting .ready in a bizarre way
[09:17:50] <jaubourg> sorry to be that late
[09:17:55] <DaveMethvin> it's a function, but we're adding the promise functionality to it
[09:17:57] <DaveMethvin> hey JamesMGreene
[09:17:59] <DaveMethvin> jaubourg:
[09:18:00] <DaveMethvin> dug
[09:18:11] <jaubourg> aubourg, james aubourg
[09:18:19] <jaubourg> (music ensues)
[09:18:21] <JamesMGreene> No worries
[09:18:22] <DaveMethvin> functionunction
[09:18:28] <jaubourg> hehe
[09:18:29] <JamesMGreene> o/
[09:18:37] <DaveMethvin> the other thing that occurred to me is
[09:18:44] <DaveMethvin> we could make jQuery.ready the promise
[09:18:51] <DaveMethvin> and move the internal function to another name
[09:18:59] <jaubourg> no, because it would mean we create it at load time
[09:19:02] <jaubourg> which we don't
[09:19:25] <jaubourg> I don't really see the problem with jQuery.ready.promise tbh
[09:20:19] <jaubourg> (you're so glad I'm here, arent you guys :P)
[09:20:23] * jaubourg dances
[09:20:48] <DaveMethvin> it just seems strange to append that functionality to a function users aren't supposed to call
[09:20:54] <gnarf> it's the magic of $.when looking for "promise"
[09:21:04] <gnarf> that makes it magic
[09:21:17] <jaubourg> we can just document $.when( $.ready ) and be done with it
[09:21:32] <jaubourg> we don't document it's a function nor that is has a promise method
[09:21:40] <gnarf> looking for a .promise() function is part of jQuery's deferred $.when that lets you not create the promise until you need it
[09:22:25] <DaveMethvin> just thinking about what this might imply for modularity
[09:22:31] <gnarf> "If you have the Deferred module, and the ready module, you can also use $.when( $.ready ) to get a promise"
[09:22:38] <DaveMethvin> for example, do we support ready without Deferred?
[09:22:42] <m_gol> right
[09:22:46] <m_gol> there's a ticket for that
[09:22:51] <m_gol> I believe I'm assigned to it
[09:23:07] * m_gol drumrolls
[09:23:15] <DaveMethvin> if we use the new .then() we get the error handling "for free" now which is good
[09:23:26] <m_gol> https://github.com/jquery/jquery/issues/1778
[09:23:34] <gnarf> if "for free" means selling our debugging rights souls
[09:24:02] <DaveMethvin> yeah, there are some sticky probs to solve
[09:24:18] <jaubourg> try { myEntireProgram() } catch( e ) { /* ignore any error */ }... gotta love "solutions" like this
[09:25:08] <DaveMethvin> oh come now it wouldn't be ignored, more like console.log("there was an error") :)
[09:25:12] <jaubourg> anyway, is ready still a thing nowadays? I thought people put their javascript at the end of the body now?
[09:25:35] <DaveMethvin> i think most people should but there's a lot of plugins out there that auto-run on ready
[09:25:42] <m_gol> jaubourg: up until recently it didn't prevent some of our support tests to return incorrect results
[09:26:11] <m_gol> * from returning
[09:26:19] <DaveMethvin> m_gol how about if we return to this question once you have looked at how 1778 is going to be solved?
[09:26:26] <DaveMethvin> ideally we'd have the promise on jQuery.ready
[09:26:36] <m_gol> k
[09:26:41] <DaveMethvin> hey markelog
[09:26:53] <markelog> hey-hey, sorry i'm late, work stuff (
[09:27:18] <markelog> did i miss something intersting?
[09:27:46] <DaveMethvin> check the notes, i think we're good
[09:27:51] <DaveMethvin> https://github.com/jquery/jquery/issues/1956
[09:28:43] <DaveMethvin> oh i meant to check what templating libs do there
[09:28:55] <DaveMethvin> it seems wrong to use the .html() method on the inside of a script tag
[09:28:58] <m_gol> so, in jQuery 1.10 .css('width') produced incorrect results if run before document ready, even if scripts were put at the end of body: http://bugs.jquery.com/ticket/14084
[09:29:15] <DaveMethvin> yeah, b/c of the delayed feature check
[09:29:17] <m_gol> so it was important to wrap in $(doc).ready
[09:29:25] <m_gol> so that's not ancient past ;)
[09:29:31] <m_gol> but now it shouldn't be a problem
[09:29:53] <m_gol> I hope
[09:30:34] <m_gol> Trac got fast when we stopped using it
[09:30:39] <DaveMethvin> yeah!
[09:30:53] <DaveMethvin> i'm going to mention a few tickets here just to see if we can clean them up
[09:30:54] <DaveMethvin> https://github.com/jquery/jquery/issues/1953
[09:31:28] <DaveMethvin> nothing back from that guy but i'm guessing it was using some aggressive settings
[09:31:48] <m_gol> possible
[09:31:53] <DaveMethvin> so i'm going to close it and he can reopen if it turns out to be something we shoud worry about
[09:31:57] <m_gol> we can't protect ourselves from that then
[09:33:02] <DaveMethvin> not in general, true
[09:33:08] <gnarf> eh
[09:33:14] <gnarf> we can test against other minifiers
[09:33:18] <DaveMethvin> if it were something that a lot of people did we could change the code
[09:33:21] <gnarf> and more agressive settings
[09:33:28] <markelog> we don't need a "noteabug" label, right?
[09:33:29] <m_gol> sure, but aggressive settings are just that - aggressive settings
[09:33:40] <DaveMethvin> i don't think we need notabug
[09:33:45] <DaveMethvin> by default it's not a bug :)
[09:33:53] <m_gol> I don't think we should work with all minifiers with no matter how aggressive options enabled
[09:34:05] <DaveMethvin> imagine our test matrix, we'd need to run unit tests with a bunch of minified copies
[09:34:11] <DaveMethvin> many of which we never shipped
[09:34:18] <m_gol> it's like we're shooting ourselves in the foot by trying to not get minified as much as possible
[09:34:25] <DaveMethvin> it's possible, just not practical
[09:34:32] <gnarf> sure
[09:34:47] <gnarf> i bet it's something jdalton would do ;)
[09:34:54] <markelog> i remember there was a problem with minifier that was used by some German celuiar network on the fly long time ago
[09:35:05] <DaveMethvin> yep, and we worked around that
[09:35:05] <m_gol> also, it's always possible that jQuery concatenated with other libs and minified only then behaves differently with some more aggressive options
[09:35:16] <m_gol> so, in fact, it's even not possible to test against such problems filly
[09:35:18] <m_gol> * fully
[09:35:24] <markelog> yeah, but it seems test on different mifiers is overkill
[09:35:25] <DaveMethvin> but we need to know about it and if it's an isolated incident then we tell them to change
[09:35:34] <markelog> they probably should test their stuff on jQuery
[09:35:42] <DaveMethvin> if it's a cell network that all of Germany uses and can't change, then we can work around
[09:36:00] <gnarf> ^
[09:36:51] <DaveMethvin> just a quick look at the pulls to see if anything needs discussion there
[09:36:54] <gibson042> right, it smacks of https://github.com/jquery/jquery/blob/d6c97abb744bfe8c67ab9158aecdb5bb1c05e47b/src/ajax.js#L39
[09:37:16] <DaveMethvin> i need to review some of those, looks like markelog submitted a few new ones
[09:37:30] <markelog> small ones :-)
[09:37:43] <m_gol> any remarks on my PR? https://github.com/jquery/jquery/pull/1949
[09:37:55] <m_gol> btw, I've just got an e-mail from some Polish guy
[09:38:13] <markelog> oh, want to check that one out, could wait until tomorrow?
[09:38:14] <m_gol> that he now has problems as the 2.1.3 tag has jsdom in dependencies and that requires python & some other build stuff present
[09:38:16] <DaveMethvin> m_gol: that looked good to me, would like to see it land
[09:38:19] <m_gol> markelog: sure
[09:38:22] <markelog> cool
[09:38:38] <m_gol> I was kinda worried about that
[09:38:49] <m_gol> but if we want to smoke-test against jsdom, we have to include it
[09:39:04] <DaveMethvin> as a devdependency tho right?
[09:39:08] <m_gol> and there are no optionalDevDependencies so far
[09:39:18] <m_gol> yes, but I suspect he was building jQuery or sth
[09:39:24] <DaveMethvin> ugh
[09:39:59] <DaveMethvin> well let's land it and we can always make changes later
[09:40:21] <DaveMethvin> the scrolltop/left one looks good to me as is, i think we should stay with the old expects() until we change to qunit 2.0 style
[09:40:28] <m_gol> ok, I'll just wait for markelog's review
[09:40:38] <markelog> yep
[09:40:55] <markelog> although i ddin't actually run tests on it
[09:41:04] <m_gol> ah, one thing
[09:41:14] <m_gol> I'd like some input about that: https://github.com/jquery/jquery/pull/1949#discussion_r22066715
[09:41:31] <m_gol> you can also read the whole thread
[09:41:39] <markelog> DaveMethvin: if you didn't, i can make couple of runs and merge it if there is no problems with it
[09:42:13] <markelog> m_gol: yeah, that is why i want to check it out )
[09:42:23] <DaveMethvin> ok i'll let markelog do the hard work :)
[09:42:35] <m_gol> so, if we go for a separate test task and still have the test_fast one, we'll have it invoked twice on TestSwarm - it's not a big problem as they're fast but I'd like to hear thoughts of others
[09:42:35] <DaveMethvin> today is crazy for me
[09:42:38] <markelog> a boring one )
[09:42:56] <DaveMethvin> if it's fast there's no problem running it twice
[09:43:03] <DaveMethvin> as long as we get it to pass both times :)
[09:43:17] <markelog> seems weird though
[09:44:01] <m_gol> yeah, maybe it's just that it feels weird than that it's an actual problem ;)
[09:44:14] <gibson042> another possible way would be disjoint test_fast and test_slow
[09:44:26] <gibson042> but I'm also ok with running explicitly fast tests twice
[09:45:05] <DaveMethvin> now that we're smoke testing npm i'd like to smoke test xhtml as well at some point
[09:45:18] <gnarf> but yeah
[09:45:23] <gnarf> its not a big deal if its fast
[09:45:25] <DaveMethvin> for that even one browser would be good
[09:45:30] <markelog> DaveMethvin: it would be fun if we would smoke test xhtml with phantom )
[09:45:32] <m_gol> it's 500 ms
[09:45:41] <DaveMethvin> maybe phantom 2.0
[09:45:51] <m_gol> PhantomJS 1.x XHTML bugs - sounds yummy!
[09:45:52] <DaveMethvin> phantom 1.x is a smoke test by itself
[09:45:57] <markelog> they gonna release soon?
[09:46:04] <m_gol> Phantom will smoke the test out
[09:46:05] <DaveMethvin> probably not :)
[09:46:16] <m_gol> it doesn't even build on OS X currently
[09:46:50] <m_gol> neither 1.x nor 2.0 :P
[09:47:03] <markelog> so how we would test xhtml?
[09:47:04] <DaveMethvin> we need real headless chrome, firefox, ie
[09:47:23] <DaveMethvin> i'd say just a single basic xhtml file with a few methods called
[09:47:31] <markelog> DaveMethvin: why not a real browser?
[09:47:38] <DaveMethvin> to ensure we didn't do anything super dumb
[09:48:03] <markelog> DaveMethvin: would be easy if we could do that with karma
[09:48:14] <markelog> so much to do, so little time (
[09:48:21] <DaveMethvin> yeah
[09:48:51] <DaveMethvin> alright, any other high priority things we should discuss?
[09:49:06] <DaveMethvin> let's just get some of these PRs landed and knock down the issues
[09:49:13] <markelog> not a high priority
[09:49:21] <DaveMethvin> i should be able to get to some later in the week
[09:49:22] <markelog> did we ever discuss code coverage?
[09:49:32] <DaveMethvin> no but we should at some point
[09:49:39] <DaveMethvin> i'd love to do that
[09:49:52] <markelog> i was thinking that we depend on the environment a lot
[09:50:06] <markelog> and that might interfere with it
[09:50:07] <jaubourg> would be quite simple when we test in node
[09:50:27] <jaubourg> yeah, covering support workarounds won't be easy ;)
[09:50:34] <DaveMethvin> yeah i don't mind if it's not perfect, we definitely would skip some of the support paths
[09:50:37] <markelog> like, how some tool will react?
[09:50:46] <markelog> if some win property doesn't exist
[09:51:07] <markelog> but we have a check for it
[09:51:11] <jaubourg> if the unit tests work, then coverage tools will
[09:51:23] <DaveMethvin> maybe we could mock the support object and run multiple times
[09:51:43] <markelog> how about i will create a ticket for it?
[09:51:48] <DaveMethvin> sounds good
[09:51:58] <jaubourg> aren't we supposed to CLOSE tickets? :P
[09:52:02] <markelog> we don't do code coverage for any jquery projects right?
[09:52:10] <markelog> ))
[09:52:11] <jaubourg> not that I know of
[09:52:13] <DaveMethvin> i vote we have jaubourg close the tickets :)
[09:52:31] <jaubourg> WONTFIX WONTFIX WONTFIX
[09:52:32] <DaveMethvin> i don't think any jquery does right now
[09:52:40] <m_gol> last time I was checking coverage in Karma it was generating correctly in Fx; Chrome gave empty output
[09:52:52] <m_gol> so I guess we could have fun with some older browsers ;)
[09:52:57] <DaveMethvin> "fun"
[09:53:03] <markelog> "fun" indeed )
[09:53:13] <m_gol> if we wanted to run it everywhere
[09:53:14] <m_gol> ;)
[09:53:47] <markelog> m_gol: but we need a karma for it, right?
[09:53:52] <m_gol> yes
[09:53:58] <markelog> or only jsdom?
[09:53:59] <m_gol> I mean, for this specific one
[09:54:07] <m_gol> but it could be done without Karma
[09:54:25] <jaubourg> damn, gotta fly guys
[09:54:28] <m_gol> there should be some tools working with jsdom
[09:54:31] <markelog> see ya!
[09:54:32] <DaveMethvin> ok then, let's try to get as much done as we can, but be sure to have a great time over the holidays ...
[09:54:36] <m_gol> but that might be a dark corner...
[09:54:49] <m_gol> coverage on jsdom when a lot of its mock APIs are not working correctly for sure
[09:54:52] <jaubourg> cya around, I'll try to derail PRs and Issues a little more in 2015 :P
[09:54:52] <DaveMethvin> i'll be around if you need me, maybe a bit slow to respond
[09:54:55] <markelog> okay, will talk more in the ticket
[09:55:13] <DaveMethvin> but i should be around for a meeting next monday as well
[09:56:41] <m_gol> I might not be terribly available until the end of the year
[09:56:43] <m_gol> too many deadlines
[09:57:25] <DaveMethvin> no problem, we'll leave plenty of work for you m_gol
[09:57:26] <DaveMethvin> :)