[09:01:40] <DaveMethvin> who's around today?
[09:02:33] <gnarf> I am
[09:02:37] <DaveMethvin> haha
[09:02:43] <gnarf> Krinkle|detached jzaefferer : https://github.com/jquery/infrastructure/issues/233 ?
[09:02:45] <DaveMethvin> just a tab away!
[09:03:05] <DaveMethvin> https://docs.google.com/document/d/1su2ZTFZbnp_DD-LGZleuEudTFRJT_g4zf7UfGOMQvco/edit
[09:03:15] <DaveMethvin> m_gol looked like he was around earlier
[09:03:23] <DaveMethvin> markelog too maybe
[09:03:35] <m_gol> present
[09:03:38] <markelog> hey-hey
[09:03:41] <DaveMethvin> it's a holiday here in the US so some people may  not be around
[09:03:58] <DaveMethvin> we're getting to be worse than the FRENCH
[09:04:01] <m_gol> DaveMethvin: where's the usual long list of nicknames to recall all lost souls? ;)
[09:04:02] <DaveMethvin> :)
[09:04:38] <DaveMethvin> i figured i'd let sleeping dogs lie since it's a holiday
[09:05:22] <DaveMethvin> so, i'd love to do a release but it sure would be nice to have some test to prove everything is working
[09:05:54] <markelog> it was a pretty frustrating incident with npm
[09:06:21] <markelog> should have spend more time checking it
[09:06:33] <markelog> although i never encounter such issue before
[09:07:03] <DaveMethvin> yeah i dunno what was up
[09:07:13] <DaveMethvin> at least we know to keep an eye on it
[09:07:20] <DaveMethvin> and it's easy to fix when it does get broken
[09:07:23] <DaveMethvin> so we can figure it out
[09:08:05] <markelog> so swarm is still "down"?
[09:08:06] <m_gol> current npm should be fine so we just should make sure we have current ones
[09:08:20] <markelog> good call
[09:08:24] <DaveMethvin> worse than down, it's really borked
[09:08:25] <gnarf> so jenkins isn't updating the git repo before building
[09:08:32] <gnarf> thats the broken part i think
[09:08:33] <m_gol> current node isn't always enough as npm updates faster
[09:08:38] <gnarf> im unaware of other broken parts
[09:08:41] <gnarf> if there are any
[09:08:49] <DaveMethvin> so why isn't it updating?
[09:08:59] <gnarf> but as far as WHY jenkins isn't updating anymore, I'm assuming this goes back to Krinkle updating jenkins plugins 4 or 5 days ago
[09:09:18] <gnarf> I tried a few things, but everything I tried just broke
[09:09:33] <markelog> can we revert?
[09:09:53] <gnarf> I don't know - I don't keep a backup of the jenkins plugins so
[09:10:31] <gnarf> https://github.com/jquery/infrastructure/issues/233 has more
[09:11:13] <DaveMethvin> ok, i'll hope it's fixed and we can do a final later this week
[09:11:45] <DaveMethvin> I'll be traveling next week, still could do a release tho
[09:11:52] <m_gol> we should have that running before releasing the final
[09:12:06] <DaveMethvin> agreed
[09:12:29] <DaveMethvin> is there anything that has to land before final? i'd prefer to say "no" unless it's critical
[09:12:44] <markelog> "no" from me
[09:12:46] <DaveMethvin> better to do a .1 release for bug fixes
[09:13:03] <gnarf> DaveMethvin: not really tho http://bugs.jquery.com/ticket/14634 is a new one on my radar
[09:13:09] <DaveMethvin> ok so nobody land anything this week
[09:13:18] <gnarf> don't want to land this pre final tho
[09:13:33] <DaveMethvin> in the meantime we can continue to work on tix and submit pull requests
[09:13:44] <m_gol> what about http://bugs.jquery.com/ticket/14680?
[09:14:09] <DaveMethvin> i think that's a .1 as well
[09:14:47] <markelog> honestly we should just try...catch it
[09:14:47] <DaveMethvin> there are a lot of bugs in IE11 it seems
[09:15:01] <markelog> event on document was clever
[09:15:06] <DaveMethvin> i am hoping they'll do some slipstreams
[09:15:21] <markelog> but it getting to complex i guess
[09:15:25] <DaveMethvin> yeah so the github blog
[09:15:52] <DaveMethvin> basically just grouping all the delegated events into a single query
[09:16:01] <DaveMethvin> rather than checking each individually
[09:16:19] <DaveMethvin> works fine for their use case but either doesn't help or breaks for a lot of others
[09:16:23] <DaveMethvin> no oldIE support either
[09:16:42] <DaveMethvin> only works on document because qSA can't do rooted queries
[09:16:44] <markelog> and it's big
[09:16:47] <DaveMethvin> very big
[09:17:04] <DaveMethvin> but i think bringing back quickIs from 1.7.2 would be a compromise
[09:17:17] <markelog> why did we remove it?
[09:17:17] <m_gol> why was it removed?
[09:17:21] <DaveMethvin> lol
[09:17:23] <markelog> -)
[09:17:26] <DaveMethvin> space saving
[09:17:31] <DaveMethvin> it's not too big tho
[09:17:32] <m_gol> DaveMethvin: now you have to answer twice
[09:17:37] <DaveMethvin> space saving :)
[09:17:41] <markelog> ))
[09:17:45] <DaveMethvin> there's an echo in here!
[09:18:09] <DaveMethvin> also i thought of another optimization that could do that would improve perf for the github case
[09:18:28] <markelog> how much did we save after it was removed?
[09:18:42] <DaveMethvin> can't recall
[09:18:52] <DaveMethvin> but we can see what it costs when i put it back
[09:18:56] <DaveMethvin> :)
[09:19:09] <m_gol> :)
[09:19:09] <DaveMethvin> i don't think it's too much
[09:19:33] <DaveMethvin> and we know that code works since we had it in previously
[09:19:51] <DaveMethvin> the github code is using a bunch of ES5 stuff and would be a pain to back-port to 1x
[09:19:59] <markelog> +1 from me, i like perf improvments
[09:20:25] <DaveMethvin> attaching 150 delegated click events to document makes me sad
[09:20:49] <DaveMethvin> but their use case is that they have a server side framework and are treating html/js/css like machine language
[09:20:52] <m_gol> DaveMethvin: what another optimization did you have in mind?
[09:21:20] <DaveMethvin> in a descendant or child selector, the rightmost thing has to match or it's not worth doing a more expensive check
[09:21:28] <markelog> i have seen something like this
[09:21:54] <DaveMethvin> it's a minor change to the regex to capture a leading space/>
[09:21:55] <markelog> i could be common for the front-end frameworks
[09:22:21] <DaveMethvin> i don't think perf gets bad until you get 100 or more events of the same type
[09:22:25] <DaveMethvin> so it's not THAT common
[09:22:35] <DaveMethvin> which explains why nobody complained about it before
[09:22:42] <DaveMethvin> or maybe they didn't pin it on jQuery :)
[09:23:04] <DaveMethvin> but anyway i think we can bring it down to reasonable levels
[09:23:14] <DaveMethvin> i was going to write a blog post about it
[09:23:19] <markelog> in the test case i have seen they (or we) used a monkey-patch, just like folks from github
[09:23:24] <m_gol> I guess some MVC frameworks might dispatch a lot of events
[09:23:45] <m_gol> esp. those with 2-way data binding
[09:23:52] <DaveMethvin> yeah, if you did it with something like "scroll" or "mouseover" then you are really screwed
[09:24:06] <DaveMethvin> but for low-freq events you'd need like 100 or more
[09:24:22] <DaveMethvin> before you'd see a problem today i'd think
[09:24:23] <markelog> although dev that do something like this probably know about issues like that
[09:24:45] <DaveMethvin> you would hope so
[09:24:51] <DaveMethvin> the github guys are sharp
[09:25:02] <DaveMethvin> and the patch they wrote is really good for their situation
[09:25:10] <DaveMethvin> but it doesn't handle anything but document
[09:25:14] <m_gol> I'm surprised it's not in CoffeScript :P
[09:25:18] <markelog> )
[09:25:20] <m_gol> given their recent tendencies
[09:25:30] <DaveMethvin> doens't work on oldIE, doesn't deal with namespaces, etc
[09:25:58] <DaveMethvin> okay, where are we? api.jquery.com
[09:26:07] <DaveMethvin> m_gol saw some of this discusson
[09:26:18] <DaveMethvin> we should really get rid of Migrate there
[09:26:21] <m_gol> scott_gonzalez said he'd go through the pages and see what plugins are involved
[09:26:33] <DaveMethvin> i'll be glad to help there
[09:26:44] <m_gol> once we have that, we can solve it in a case-by-case basis
[09:26:49] <DaveMethvin> yeah i doubt it's too hard
[09:26:57] <DaveMethvin> and we can push the fixes upstream if we need to
[09:27:08] <m_gol> and as I said, either the plugin is dead and forking doesn't really introduce overhead for us
[09:27:16] <m_gol> or it's alive so it should accept compatibility patches
[09:27:22] <DaveMethvin> yeah
[09:27:37] <DaveMethvin> ok so m_gol  you good with pitching in once scott_gonzalez has the list?
[09:27:43] <m_gol> yup
[09:27:54] <gnarf> don't forget
[09:27:59] <gnarf> it's every site on the wordpress
[09:28:02] <gnarf> not just api ;)
[09:28:06] <DaveMethvin> yeah
[09:28:09] <scott_gonzalez> Thanks. I have a feeling that finding the pages will be the hard part, but we'll see.
[09:28:18] <m_gol> haha
[09:28:45] <DaveMethvin> turn on those Migrate messages and we can track it down for sure
[09:29:17] <DaveMethvin> okay, last item i had, 1.12/2.2 discussion for San Diego
[09:29:56] <DaveMethvin> I'll send around a document, you can throw ideas in there and we can review what's already in Trac as well
[09:30:16] <DaveMethvin> gibson042!
[09:30:26] <DaveMethvin> yay
[09:30:37] <gibson042> yeah, looks like my IRC penalty box session finally expired :)
[09:30:47] <DaveMethvin> just about ready to wrap ... did anyone else have anything?
[09:30:53] <markelog> when do we release final version?
[09:31:04] <DaveMethvin> i hope later this week, thu or fri
[09:31:16] <DaveMethvin> but it depends on the test infrastructure
[09:31:29] <markelog> okay, if no one minds i would like try again
[09:31:31] <m_gol> can someone add IE11?
[09:31:34] <m_gol> I don't have proper keys
[09:31:42] <DaveMethvin> oh to the test mix?
[09:31:46] <m_gol> yup
[09:31:59] <m_gol> I only did what I could which is adding the entry to localSettings.json
[09:32:07] <DaveMethvin> i'm not sure i do either
[09:32:10] <m_gol> now sb must join the swarm with IE11
[09:32:28] <m_gol> as Krinkle pointed out, instructions are here: https://github.com/jquery/infrastructure/wiki/TestSwarm#add-a-browser
[09:32:40] <markelog> well, first we have to make swarm work again
[09:32:43] <markelog> )
[09:32:50] <m_gol> so I just modified userAgents
[09:32:54] <m_gol> haha, true
[09:33:28] <m_gol> as for publishing
[09:33:36] <m_gol> how do we handle beta/latest tags?
[09:33:47] <m_gol> it seems `npm publish` by default updates `latest`
[09:33:58] <markelog> npm publish --beta
[09:34:01] <m_gol> which can make `1.11.0` latest instead of `2.1.0` which we want
[09:34:09] <DaveMethvin> it was like --tag beta i think
[09:34:21] <m_gol> doesn't --beta set the beta dist-tag?
[09:34:25] <markelog> right
[09:34:33] <m_gol> because that's not what we want
[09:34:40] <DaveMethvin> whoops
[09:34:57] <scott_gonzalez> latest should be 2.x.
[09:35:05] <m_gol> yes
[09:35:09] <scott_gonzalez> We can have a tag for 1.x for browserify uses.
[09:35:14] <scott_gonzalez> If we decide to do that.
[09:35:17] <DaveMethvin> we could publish in order 1.11, 2.1 worst case
[09:35:21] <m_gol> yeah, was thinking about that, too
[09:35:22] <scott_gonzalez> They can also just say "jquery": "1.x"
[09:35:37] <scott_gonzalez> Which seems like the sane way to do 1.x latest.
[09:35:42] <m_gol> right
[09:35:54] <m_gol> so does --beta set the beta dist-tag or not? anyone knows?
[09:36:21] <DaveMethvin> i think we did --tag beta, it's in the irc log from thursday
[09:36:24] <scott_gonzalez> `npm publish --tag beta` will update the beta tag, not the latest tag.
[09:36:38] <m_gol> so how to make it not update any tags?
[09:36:43] <m_gol> bc that's what we want for 1.x
[09:37:09] <scott_gonzalez> I'm not sure if we can. We should ask in #node.js
[09:37:10] <m_gol> when we release 2.1.0, both latest & beta should be 2.1.0, we don't want beta to be 1.11.0
[09:37:19] <DaveMethvin> --tag ignorethistag
[09:37:22] <scott_gonzalez> haha
[09:37:46] <DaveMethvin> --tag notthedroids
[09:38:13] <DaveMethvin> anyway that must be a solveable problem, we'd need to think about how we'd want to do that in core since we publish both
[09:38:26] <DaveMethvin> really, doing in order of 1.11, 2.1 might be easiest
[09:38:34] <m_gol> yes, I don't think having to remember to publish 1.x first is a viable solutoon
[09:38:41] <m_gol> we'll forget
[09:38:43] <DaveMethvin> i rarely remember anything
[09:38:44] <scott_gonzalez> I actually don't think I've ever seen someone use "latest" as the version in npm.
[09:38:56] <m_gol> or we'll have to republish one of them and we'll forget we now have to reset the tag
[09:38:58] <DaveMethvin> neither have i
[09:38:58] <scott_gonzalez> It's either ranges, *, or specifc.
[09:39:00] <scott_gonzalez> Or SHA
[09:39:05] <scott_gonzalez> But I've never seen anyone use latest.
[09:39:10] <m_gol> scott_gonzalez: npm install package installs package@latest
[09:39:18] <scott_gonzalez> ohh...
[09:39:19] <m_gol> so yes, a lot of people actually use it implicitely
[09:39:27] <scott_gonzalez> That makes sense.
[09:39:36] <DaveMethvin> whelp, that means we should make it work :)
[09:40:07] <scott_gonzalez> Let's track this in the jquery-release repo.
[09:40:11] <scott_gonzalez> I'll open an issue right now.
[09:40:13] <m_gol> ok
[09:40:31] <DaveMethvin> anything else?
[09:40:36] <m_gol> haha, it may turn out `npm publish --tags "1.x"` will be the least painful solution to the problem :P
[09:41:16] <DaveMethvin> on markelog's request to add IE11, who can do that?
[09:41:30] <markelog> amm
[09:41:36] <scott_gonzalez> https://github.com/jquery/jquery-release/issues/29
[09:41:38] <markelog> m_gol i think?
[09:41:45] <DaveMethvin> i saw the ua parser changes fly by
[09:41:50] <m_gol> I can if I have the keys
[09:41:59] <scott_gonzalez> Heh, I wonder if anyone has created a tag that clashes with version ranges.
[09:41:59] <m_gol> and if jenkins starts cooperating ;)
[09:42:26] <DaveMethvin> who has keys? gnarf i am sure
[09:42:26] <m_gol> right... they're specified in the same way so that might be problematic
[09:43:56] <DaveMethvin> okay then, i have to run and it sounds like we're done
[09:44:09] <DaveMethvin> see you guys in -dev!
[09:44:11] <DaveMethvin> thanks