[09:00:03] <DaveMethvin> https://docs.google.com/document/d/1BadwSO6Sn91RBfr05s77r81ncEi0oMBJ5mZS-k215vg/edit
[09:01:29] <arthurvr> Hi guys!
[09:01:52] <gibson0421> hi!
[09:01:54] <markelog> hey-hey
[09:02:24] <DaveMethvin> hey!
[09:02:48] <DaveMethvin> getting a bit of a late start
[09:02:57] <DaveMethvin> but we have a fresh 2015 file!
[09:04:28] <DaveMethvin> so we really  need to get a lot done this week
[09:05:04] <gibson0421> you can say that again
[09:05:34] <markelog> true that!
[09:05:36] <DaveMethvin> on the prs that are there, i think we should just go through and land whatever is safe to land
[09:05:46] <DaveMethvin> like, for indexOf i'm okay with that
[09:05:55] <DaveMethvin> to make it work long term we need some style guidance
[09:06:24] <markelog> and probably check for it too, it seems very specific
[09:06:27] <DaveMethvin> but that doesn't have to block that pr landing
[09:06:29] <gibson0421> yeah, I basically figured I'd leave this meeting as an opportunity to object to anything in https://github.com/jquery/jquery/pulls/gibson042 and land whatever had none
[09:07:08] <DaveMethvin> just running down the list of prs now
[09:07:22] <markelog> on https://github.com/jquery/jquery/pull/1991
[09:07:50] <markelog> maybe wait until jaubourg opinion?
[09:08:12] <markelog> +1 for indexof
[09:08:15] <DaveMethvin> gibson0421: was that a yak you were shaving for the .then()?
[09:08:21] <gibson0421> yep
[09:08:25] <DaveMethvin> haha figure
[09:08:27] <DaveMethvin> d
[09:08:32] <gibson0421> indexOf and callbacks both, actually
[09:08:39] <markelog> +1 commitplease
[09:08:54] <markelog> -1 for grunt tasks
[09:09:05] <gibson0421> why?
[09:09:34] <gibson0421> right now `grunt test` does a build
[09:09:36] <gibson0421> it's crazy
[09:09:56] <markelog> yeah it should be improved
[09:09:57] <m_gol> Hi
[09:10:05] <DaveMethvin> hey m_gol
[09:10:14] <markelog> but i think we could do it much more simplier
[09:10:27] <DaveMethvin> well it's hard to test some things without building, and if anything it will get worse
[09:10:31] <markelog> like now we trying to prepare for new task to come
[09:10:36] <gibson0421> I see where you're coming from, but I don't want it to go astray when the complexity does come in
[09:11:01] <markelog> a lot could and probably will change at that point
[09:11:08] <markelog> look at sizzle grunt test tasks
[09:11:20] <markelog> they really not what i'd would expect
[09:11:20] <gibson0421> they fit the general pattern
[09:11:44] <markelog> new tasks might or might not
[09:12:02] <gibson0421> would anyone still object to the pull if I remove test_fast and replace it with the node smoke test?
[09:12:06] <markelog> but we probably shouldn't complicate things for stuff we don't currently have
[09:12:23] <gibson0421> if that's the point of contention, I'll drop the redundant grunt task
[09:12:38] <DaveMethvin> i'm not bothered either way
[09:13:13] <markelog> why you don't think lint task should not be in the test task?
[09:13:18] <DaveMethvin> there are some deeper issues with our whole grunt setup that bother me a LOT more, but that's more about grunt
[09:13:23] <m_gol> A conmon npm idiom is "npm install && npm test"
[09:13:29] <markelog> DaveMethvin: like?
[09:13:46] <DaveMethvin> the complexity of the gruntfile and the difficulty of tracing what happens
[09:13:48] <m_gol> Which means that if the package needs building, "npm test" does the build first
[09:13:49] <gibson0421> and that's fine, but grunt is not npm
[09:13:55] <markelog> gibson0421: +1
[09:13:57] <markelog> and
[09:13:59] <markelog> (
[09:14:08] <gibson0421> so npm test is "grunt default && grunt test"
[09:15:43] <gibson0421> cool?
[09:15:48] <markelog> sec
[09:16:03] <DaveMethvin> this isn't major stuff so i'm good with it
[09:16:09] <DaveMethvin> if it turns out we need to change it later, fine
[09:16:16] <markelog> what would be in the "grunt test"?
[09:16:22] <markelog> lint?
[09:16:29] <markelog> or it would be in the "grunt default"
[09:16:30] <gibson0421> right now, just node smoke test
[09:16:45] <gibson0421> lint is part of grunt default
[09:16:45] <markelog> so why not lint?
[09:17:14] <gibson0421> lint is a build/pre-build task; testing is post-build
[09:17:26] <markelog> DaveMethvin: me and Richard just argue about colon for couple of days, i guess we are very detail oriented )
[09:17:33] <gibson0421> lol
[09:17:47] <m_gol> I'm generally fine with what gibson0421 says although I see that linting can be seen as kind of a test
[09:17:56] <markelog> but you can build without lint
[09:18:10] <markelog> but you should lint before you test
[09:18:12] <m_gol> especially that my recent commit adding Node smoke testing changed jsHint setup in a way that most issues caught by the Node smoke test will be caught by jsHint
[09:18:42] <markelog> static analizers usually considered as kind of a test
[09:18:55] <markelog> *analyzers
[09:18:58] <gibson0421> "test" in task parlance refers to analyzing behavior
[09:19:02] <DaveMethvin> i can see "test" doing some sort of headless testing in the future
[09:19:09] <gibson0421> YES
[09:19:09] <m_gol> the thing is that we cannot run tests before we build but we can run linters before we do
[09:19:15] <gibson0421> exactly
[09:19:15] <markelog> DaveMethvin: yep
[09:19:27] <m_gol> or we could *mostly* as we run them on the built file as well for one minor reason ;)
[09:19:32] <markelog> DaveMethvin: but we have to do a lot to come to this point
[09:19:36] <m_gol> * concatenated file, before uglifying
[09:19:44] <DaveMethvin> let's just land this, so many things need to be done we shouldn't get caught up on it
[09:19:55] <DaveMethvin> like colons :)
[09:19:58] <gibson0421> we lint as soon as possible, which unfortunately happens after concatenation
[09:20:00] <gibson0421> ok
[09:20:01] <markelog> lol
[09:20:13] * gibson0421 suppresses medical joke
[09:20:17] <markelog> okay, how about i will send a PR, maybe just for the discussion about it
[09:20:24] <DaveMethvin> ok
[09:20:27] <markelog> good
[09:20:39] <markelog> okay, so we have a schedule right?
[09:20:40] <m_gol> tbh I find it weird that the dev task marked as "a hight frequency watch task" does build:*:* & lint; it's all pretty arbitrary
[09:20:54] <markelog> when do we planning on releasing 3.0 beta?
[09:21:09] <gibson0421> yeah, I don't touch that one because I don't use grunt watch
[09:21:12] <markelog> m_gol: yeah it is
[09:21:21] <DaveMethvin> i'd really like to get one out soon
[09:21:23] <markelog> gibson0421: why not?
[09:21:30] <DaveMethvin> but we need to land the features and major changes
[09:21:32] <markelog> let me guess
[09:21:35] <DaveMethvin> that includes .then() etc
[09:21:40] <markelog> you build once, then change the source
[09:21:53] <markelog> then port your changes to the modules?
[09:21:56] <gibson0421> lol
[09:21:57] <gibson0421> no
[09:22:15] <gibson0421> DaveMethvin: right; I'm in it now
[09:22:21] <gibson0421> lots of yaks, and lots of sharp corners
[09:22:43] <DaveMethvin> on https://github.com/jquery/jquery/pull/1988
[09:22:45] <markelog> features & major changes are then()
[09:22:48] <markelog> ?
[09:22:51] <m_gol> gibson0421: I figured that's where the Callbacks PRs/issues came from ;)
[09:23:05] <DaveMethvin> do all browsers allow a ":" char when using createElement() ?
[09:23:12] <markelog> yep
[09:23:16] <DaveMethvin> i just had a bad feeling, so good
[09:23:17] <markelog> as far as i know
[09:23:20] <gibson0421> yes, but they do it wrong
[09:23:36] <gibson0421> not all <svg:svg> are created equal
[09:24:01] <markelog> this an edge case for most users, we could leave this as-is, i don't really mind, but i think we should add tests
[09:24:06] <gibson0421> +1
[09:24:18] <DaveMethvin> can one of you get to it this week?
[09:24:21] <markelog> but #1988 is not about colon, this is separate issue
[09:24:35] <markelog> contributor should add couple more tests i think
[09:24:38] <DaveMethvin> oh right
[09:24:43] <markelog> and we would be ready to land it
[09:24:43] <gibson0421> yes, I agree
[09:24:51] <markelog> DaveMethvin: yeah, i can
[09:25:30] <DaveMethvin> https://github.com/jquery/jquery/pull/1975
[09:26:50] <markelog> try..catch might not be necessary, we did it, as it seems, only for "just in case" reason
[09:27:27] <markelog> if we not using ajax props of the support object anywhere else
[09:27:30] <markelog> we can remove it
[09:27:37] <DaveMethvin> that particular PR  looks like it should be okay but https://github.com/jquery/jquery/issues/1967 not so much
[09:27:37] <markelog> but, we could use it in tests
[09:28:05] <m_gol> so, the discussion was if we can remove support.cors entirely
[09:28:13] <m_gol> and just do a cross-origin request when asked
[09:28:14] <markelog> "not so much"?
[09:28:15] <DaveMethvin> and i don't think we can
[09:28:39] <DaveMethvin> non-browser envs need some way to override the normal CORS detection
[09:28:50] <m_gol> what's the use case of blocking the request in such a scenario?
[09:28:55] <m_gol> yes, but the question was if we need to guard at all
[09:29:10] <markelog> i remember there is the way to do that in exposed interface
[09:29:16] <DaveMethvin> oh that's because of the transport ness
[09:29:17] <m_gol> then libs wouldn't need to overwrite anything
[09:29:18] <DaveMethvin> mess
[09:29:32] <DaveMethvin> if you don't have cors and there are other transports, you look for those
[09:29:40] <DaveMethvin> like script
[09:29:47] <markelog> right
[09:29:56] <DaveMethvin> if this was just XHR i agree, try doing it and let it fail
[09:30:08] <m_gol> hmm, ok
[09:30:08] <DaveMethvin> another side-effect of a complex $.ajax
[09:30:33] <markelog> not sure if i understand :-)
[09:30:44] <markelog> i'm thinking of removing support.cors
[09:30:48] <DaveMethvin> if there was just one "transport" you'd just tell xhr to try
[09:30:56] <markelog> but not the guard for it check
[09:31:15] <DaveMethvin> i suppose we could have it try XHR if the answer was "no transport"
[09:32:10] <markelog> okay, so two questions
[09:32:17] <markelog> 1. do we want to leave try..catch
[09:32:25] <markelog> 2. do we remove support.cors?
[09:32:44] <DaveMethvin> 1 let's try removing it
[09:32:48] <DaveMethvin> 2 we have to keep it (or some similar thing) for non-browser envs
[09:32:54] <m_gol> jaubourg was afraid of envs that have XHR but it throws
[09:33:04] <m_gol> seems weird, though
[09:33:05] <markelog> DaveMethvin: what is use-case?
[09:33:07] <DaveMethvin> let's have those people report to us
[09:33:17] <markelog> DaveMethvin: +1, yep, yep
[09:33:25] <DaveMethvin> markelog: the use case on 2?
[09:33:31] <markelog> DaveMethvin: yeah
[09:33:43] <markelog> DaveMethvin: do we want to people test stuff in those envs?
[09:34:05] <markelog> DaveMethvin: or allow people to use jQuery in those envs?
[09:34:11] <DaveMethvin> for example, some embedded browser setups like phonegap have an XHR that allows requests to any domain without credentials
[09:34:25] <DaveMethvin> if you google for "jquery.support.cors" you'll see where it's used :)
[09:34:33] <gibson0421> I like the idea of dropping support.cors and letting XHR be the default transport
[09:35:03] <m_gol> if that works, +1 from me as well
[09:35:10] <DaveMethvin> me too gibson0421 but i wonder what strange behavior that might create
[09:35:26] <m_gol> it just doesn't feel right to tell people to use some non-standard setting we might remove one day ;)
[09:35:30] <DaveMethvin> i mean, if there's no transport it was gonna fail anyway
[09:35:33] <gibson0421> like you said, let them report it
[09:35:39] <DaveMethvin> so we try xhr
[09:36:10] <m_gol> we will definitely need a 3.0.0-rc before the release (after a beta or two) to get more people to test it
[09:36:19] <DaveMethvin> yes
[09:36:38] <DaveMethvin> right now i just want to get the important chunks in there so we can get people testing
[09:37:00] <DaveMethvin> no doubt we'll need a 3.0.1 but hey, we tried
[09:37:13] <DaveMethvin> and i'd rather try to clean these up now than wait for a long time
[09:37:18] <markelog> DaveMethvin: yeah, we changing a lot
[09:37:26] <m_gol> sure, the future DaveMethvin :)
[09:37:27] <DaveMethvin> well, yes and no
[09:37:35] <DaveMethvin> we're changing a lot of edge behaviors
[09:37:44] <DaveMethvin> but most code shoudl be fine don't you think?
[09:37:47] <markelog> i mean in general
[09:37:58] <markelog> raf, standart then, etc;
[09:38:10] <markelog> DaveMethvin: i hope!
[09:38:20] <DaveMethvin> if we really break something we can revert it
[09:38:38] <markelog> there is always that )
[09:38:51] <markelog> or force-push!
[09:39:20] <m_gol> k; I'd like to try to tackle https://github.com/jquery/jquery/issues/1684 for 3.0.0
[09:39:29] <m_gol> see this comment in particular: https://github.com/jquery/jquery/issues/1684#issuecomment-62149251
[09:39:54] <DaveMethvin> m_gol: that would be great
[09:39:55] <markelog> yeah, i think we should resolve that before the release
[09:40:14] <gibson0421> we still need the .data changes too
[09:40:19] <gibson0421> lots of stuff in https://github.com/jquery/jquery/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.0.0
[09:40:39] <markelog> gibson0421: aren't they ready?
[09:40:43] <markelog> data stuff?
[09:41:05] <gibson0421> consistent handling, in particular around digits and hyphens
[09:41:28] <markelog> is that an issue or comment in pull?
[09:41:40] <gibson0421> https://github.com/jquery/jquery/issues/1751#issuecomment-67721150
[09:41:50] <markelog> so comment in issue )
[09:42:19] <m_gol> in particular, this list: https://github.com/jquery/jquery/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.0.0+no%3Aassignee
[09:42:23] <m_gol> unassigned issues
[09:43:14] <DaveMethvin> yes, i need to go through and push some of those
[09:43:14] <DaveMethvin> the download builder can happen after the release on its own timeline
[09:45:05] <m_gol> right
[09:45:32] <DaveMethvin> i'll make a pass through the unassigned ones, i think several are pretty easy
[09:46:03] <m_gol> markelog: the data-URI test is flakey, it fails often on iOS/Opera
[09:46:18] <markelog> link?
[09:47:05] <markelog> on opera?
[09:47:05] <m_gol> markelog: I've restarted those builds to see if this is a genuine issue but generally it sometimes returns `true` instead of `"foo"`
[09:47:07] <markelog> m_gol: could create an issue and assign on me?
[09:47:15] <m_gol> markelog: I'll send you a link next time I see it & create an issue
[09:47:21] <markelog> i will check it out with that other case
[09:47:28] <markelog> cool
[09:48:35] <markelog> fast
[09:48:36] <markelog> !
[09:49:13] <m_gol> I have a couple of Android bugs in the backlog; I've been quite busy at the end of the year and I'm at the finish of it so I'll look into it soon
[09:50:36] <DaveMethvin> timmywil: would you be able to work on the build tasks in the next week?
[09:50:57] <DaveMethvin> e.g. https://github.com/jquery/jquery/issues/1869
[09:51:03] <m_gol> btw
[09:51:07] <DaveMethvin> and the others assigned to you
[09:51:12] <m_gol> that will mean the distribution repo will need to have all tags recreated
[09:51:25] <m_gol> for Bower's case
[09:51:40] <DaveMethvin> hey we can abuse the dist repo all we want
[09:51:53] <DaveMethvin> i just don't want all that crap in our dev repo
[09:52:05] <DaveMethvin> it's getting crazy
[09:52:55] <m_gol> right
[09:55:01] <DaveMethvin> okay, any other critical items? It's mainly a case of getting it done :)
[09:55:20] <m_gol> on thing
[09:55:22] <m_gol> * one
[09:55:26] <m_gol> re BrowserStack
[09:55:50] <m_gol> they're having problems with "special" things like Java applets or PATCH requests
[09:55:51] <DaveMethvin> that damn thing is always broken :)
[09:55:56] <m_gol> the Java one is discussed but the PATCH
[09:55:59] <m_gol> so I wonder
[09:56:14] <m_gol> if we could skip PATCH tests for browsers other than IE on TestSwarm
[09:56:23] <DaveMethvin> i was gonna suggest that for now
[09:56:29] <m_gol> we don't have any special logic for other browsers anyway
[09:56:39] <m_gol> and IE doesn't seem to have such problems on BrowserStack
[09:56:55] <m_gol> and even if it does sometimes, it'll still happen less often than when we do it everywhere
[09:57:03] <DaveMethvin> yeah go ahead, lets get rid of spurious fails
[09:57:17] <m_gol> k, if no one objects, I'll create an issue
[09:57:18] <m_gol> and do it together with the Java one
[09:57:53] <DaveMethvin> ok, awesome
[09:58:03] <DaveMethvin> let's get a lot of stuff done this week, thanks!