[09:00:58] <DaveMethvin> hey everybody!
[09:01:52] <DaveMethvin> looks like markelog gibson042 timmywil m_gol rwaldron ... did i miss anybody?
[09:01:58] <DaveMethvin> maybe jaubourg will show up
[09:02:05] <timmywil> caio
[09:02:17] <DaveMethvin> man that italiano is rubbing off on you timmywil
[09:02:19] <timmywil> ciao
[09:02:26] <timmywil> can't spell
[09:02:38] <gibson042> coai to you too :)
[09:02:47] <timmywil> cow
[09:02:50] <DaveMethvin> icao
[09:03:12] <DaveMethvin> better than my french i'm sure
[09:03:25] <DaveMethvin> definitely better than my russian
[09:03:34] <markelog> hey-hey
[09:03:42] <DaveMethvin> hey markelog
[09:03:55] <markelog> ))
[09:04:04] <DaveMethvin> i don't see anyone in the doc https://docs.google.com/document/d/1su2ZTFZbnp_DD-LGZleuEudTFRJT_g4zf7UfGOMQvco/edit
[09:04:16] <DaveMethvin> oh NOW i do !
[09:05:12] <DaveMethvin> okay
[09:05:27] <DaveMethvin> its one of those days when i end up with the same doc open in 3 tabs
[09:05:45] <DaveMethvin> so Trac
[09:05:54] <DaveMethvin> i have basicallly locked it down now
[09:06:03] <m_gol> present
[09:06:05] <DaveMethvin> most accounts are deleted, just ours are around still
[09:06:19] <DaveMethvin> you can create/edit/comment on a ticket or close it
[09:06:35] <DaveMethvin> but others can't create tickets or comment or create new accts
[09:06:58] <DaveMethvin> it's still dog slow and we need it to be migrated/fixed
[09:07:07] <DaveMethvin> but at least we can do new tix on github
[09:07:43] <m_gol> is it all because of a misconfigured anti-spam setup?
[09:07:46] <markelog> so people can't comment on existing issues?
[09:07:54] <DaveMethvin> markelog: no
[09:07:56] <m_gol> I still wonder why UI Trac works
[09:08:16] <m_gol> DaveMethvin: that's why I commented it's now important to migrate open issues
[09:08:20] <DaveMethvin> if we need an issue to be active i think we should open a new ticket on gh
[09:08:29] <DaveMethvin> but before we do that we need to clean up what is there
[09:08:35] <DaveMethvin> and i was finding that impossible to do
[09:08:37] <markelog> DaveMethvin: probably yes
[09:08:39] <m_gol> do we have a lot of closed issues with 2.2/1.12 milestone?
[09:08:41] <DaveMethvin> becuase its not reliable
[09:09:05] <DaveMethvin> m_gol we'll need to look, those would be good to  migrate forward since otherwise its hard to create the change log
[09:09:07] <m_gol> this one changelog will be hard to create ;)
[09:09:10] <DaveMethvin> :)
[09:09:14] <m_gol> haha, thought the same ;)
[09:09:28] <markelog> right
[09:10:10] <DaveMethvin> i don't think there are too many are there? let me see if trac will generate a report
[09:10:27] <DaveMethvin> COME ON TRAC!
[09:10:31] <m_gol> I'm trying as well
[09:10:47] <DaveMethvin> whoa, two users at once? this poor site! :)
[09:10:53] <m_gol> maybe 2 people trying at the same time is impossible for Trac
[09:10:56] <m_gol> ;)
[09:11:14] <DaveMethvin> well let's assume this can be done
[09:11:35] <DaveMethvin> in the worst case we just copy/paste the content into a gh issue to ensure it is visible in one place
[09:12:26] <m_gol> 16 tickets
[09:12:31] <DaveMethvin> that's not bad
[09:12:44] <DaveMethvin> and i think there are prob about 80 open tickets once we triage the newer ones
[09:13:08] <m_gol> yeah, we can triage first and move if it's actually a bug
[09:13:22] <DaveMethvin> many are the "boil the ocean and break all code" type of tickets which we may want to just close and document as wontfix
[09:13:26] <m_gol> with a message that from now on tickets should be created at <link to GitHub>
[09:13:28] <DaveMethvin> unless we plan to tackle
[09:13:32] <DaveMethvin> yeah
[09:13:49] <m_gol> I can help with that, just not before Wednesday :)
[09:13:54] <DaveMethvin> sounds good
[09:14:12] <DaveMethvin> mikesherov: did you talk to domenic about error handling for Promise?
[09:14:37] <DaveMethvin> we'll push that for now
[09:14:53] <DaveMethvin> what needs to be done on the Promise/A PR?
[09:15:16] <gibson042> I didn't get a chance to submit a PR yet, but I will later this week
[09:15:22] <gibson042> for alternate options
[09:15:28] <m_gol> see https://github.com/jquery/jquery/commit/d0e5c0447775239edc7819960b7c61b4b71d402f#commitcomment-7914547
[09:15:51] <m_gol> jaubourg has already switched from Q to the standard Promise in tests
[09:16:01] <DaveMethvin> which is good
[09:16:03] <m_gol> we also need to package jsdom for the browsers instead of node
[09:16:19] <m_gol> it's supposed to be possible, I just haven't had time to tackle it yet
[09:17:38] <m_gol> we can always switch later, I just wanted to have better browser coverage and easier `npm install` as jsdom requires some stuff for building, e.g. Visual Studio on Windows
[09:17:50] <DaveMethvin> ugh
[09:18:04] <m_gol> we won't be able to run those tests in pre-ES5 browsers due to use of getters
[09:18:33] <m_gol> and I don't want us to manually cherry-pick those tests out just so that IE8 plays nice
[09:18:41] <DaveMethvin> i guess that's okay since we're just testing for Promise/A compliance
[09:18:56] <DaveMethvin> we need some basic tests outside that tho
[09:18:56] <m_gol> not sure how to intergrate it with the TestSwarm+QUnit interface, though
[09:19:33] <m_gol> I guess I can wrap it in one QUnit test that will collect failures and report them in a message
[09:19:40] <m_gol> we can always then reproduce this stuff locally
[09:20:08] <DaveMethvin> sounds a little tricky, but as long as it works consistently in the swarm i'm good with it
[09:20:14] <m_gol> so, I'll look at better integration of these tests
[09:20:18] <DaveMethvin> thanks!
[09:21:31] <DaveMethvin> ok $.xhr
[09:22:02] <DaveMethvin> i think the examples we have are pretty simple, are there more complex things that we are missing?
[09:22:14] <markelog> sure
[09:22:19] <DaveMethvin> perhaps the best thing to do is to get a real implementation and try usin git
[09:22:21] <DaveMethvin> using it
[09:22:23] <markelog> but we have to found them somewhere
[09:22:41] <gibson042> the big gap I see is `ajaxSettings`
[09:22:42] <timmywil> DaveMethvin: agreed. We'll know better once we play with some code.
[09:23:16] <DaveMethvin> so we definitely don't want ajaxSettings as a global, but having some way to "pre-configure" is really handy
[09:23:42] <DaveMethvin> the chaining interface makes that harder i guess
[09:23:53] <gibson042> I don't even want to go that far ahead just yet, but we should see what problems ajaxSettings is used to address right now
[09:23:56] <DaveMethvin> an options object can always be merged and kept aroun
[09:24:17] <gibson042> though I think both xhr models will address it with a factory pattern
[09:24:36] <DaveMethvin> https://github.com/search?q=ajaxsetup&ref=reposearch&type=Code&utf8=%E2%9C%93
[09:25:01] <DaveMethvin> ugh, traditional
[09:25:19] <markelog> i thought we decided on not using global settings for new interface?
[09:25:23] <DaveMethvin> $.ajaxSetup({
[09:25:23] <DaveMethvin> 	    type: 'post'
[09:25:23] <DaveMethvin> 	});
[09:25:30] <DaveMethvin> definitely not using global settings markelog
[09:25:41] <DaveMethvin> people do crap like that!
[09:25:49] <markelog> ajaxSettings = global settings?
[09:25:51] <DaveMethvin> imagine using third-party code in that page
[09:26:07] <markelog> i'm that is why i'm not sure about this
[09:26:08] <DaveMethvin> yeah but gibson042 was asking what problems people are solving with it
[09:26:16] <markelog> oh, right
[09:26:20] <gibson042> exactly
[09:26:21] <DaveMethvin> not that we need to have it but we need to be sure we solve those use cases
[09:26:37] <DaveMethvin> and it can take extra code for odd cases, i don't worry about that
[09:26:47] <markelog> cache, timeout?
[09:27:09] <DaveMethvin> man, dataType:text
[09:27:18] <DaveMethvin> that's mean
[09:27:31] <m_gol> I love $.ajaxSetup({type: 'post'});
[09:27:40] <DaveMethvin> async:false!
[09:27:42] * gibson042 shudders
[09:27:56] <markelog> DaveMethvin: that is the best one :-)
[09:28:03] <DaveMethvin> let me visit a porn site to clear my eyes
[09:28:03] <m_gol> $.ajaxSetup({break: 'all-the-things'})
[09:28:08] <markelog> ))
[09:28:26] <DaveMethvin> yeah i understand cache:false
[09:28:29] <m_gol> I'm laughing so hard at async:false
[09:28:46] <DaveMethvin> if we didn't have to trash up the url to do it i'd prefer that be the default
[09:28:51] <DaveMethvin> and it is for all but IE
[09:29:42] <gibson042> headers (Authorization, X-CSRF-Token, etc.)
[09:29:59] <gibson042> Accept
[09:30:03] <DaveMethvin> yeah, most of the rest look like they could be handled pretty easily
[09:30:19] <DaveMethvin> with some sort of factory
[09:30:37] <gibson042> ok, cool
[09:30:42] <markelog> sounds good
[09:30:58] <DaveMethvin> so markelog did you want to give the implmentation a try?
[09:31:06] <markelog> ready to do it
[09:31:10] <DaveMethvin> go for it!
[09:31:23] <markelog> cool, for the next week i will have something
[09:31:24] <markelog> but
[09:31:29] <markelog> Deferreds?
[09:31:35] <markelog> shouldn't that come first?
[09:31:49] <markelog> i mean compliance and all that
[09:31:58] <gibson042> I would just assume a jQuery.Promise or similar
[09:32:01] <m_gol> you should be able to test on jaubourg's patch
[09:32:09] <DaveMethvin> yeah, per our older discussion
[09:32:10] <markelog> i could build up from gibson042 PR
[09:32:20] <DaveMethvin> but i think you can get most of it done from what we have so far
[09:32:20] <markelog> all right
[09:32:49] <gibson042> we promise you'll have a compliant interface on which to depend
[09:32:58] <gibson042> pun regrettably intended
[09:33:04] <markelog> but since there still be an $.ajax interface, we could/should re-use some of it parts
[09:33:18] <markelog> that might mean more little modules
[09:33:21] <DaveMethvin> i'll be interested to see how much of it could be reused
[09:33:50] <markelog> so do it right it might not take one/two nights
[09:33:51] <DaveMethvin> if it could be reused i suspect it would be via the xhr.js transport that $.ajax uses
[09:33:58] <markelog> probably
[09:34:04] <DaveMethvin> but i would be interested in a standalone impl to start
[09:34:14] <DaveMethvin> it will make it easier for us to iterate
[09:34:14] <markelog> oh, all right
[09:34:23] <DaveMethvin> and once we have a final impl we can look at integration
[09:34:30] <DaveMethvin> and see what it buys us as far as size
[09:34:33] <markelog> understood
[09:34:44] <DaveMethvin> cool
[09:34:59] <DaveMethvin> so i wanted to talk about version numbering again
[09:35:04] <DaveMethvin> NO WAIT COME BACK!
[09:35:08] <DaveMethvin> :)
[09:35:15] <m_gol> :D
[09:35:30] <m_gol> if we didn't have 2 branches, we could even publish just one package
[09:35:33] <m_gol> and have different files
[09:35:34] <DaveMethvin> i am wondering what will be the least confusing thing
[09:35:34] <markelog> maybe i missed that, but why we aren't following semver for 1.x?
[09:35:36] <m_gol> like Lo-Dash
[09:35:41] <m_gol> but it's hard to do with 2 branches
[09:36:02] <m_gol> markelog: we're trying to start following semver now which means no 1.12/2.2 but 3.0 instead
[09:36:13] <DaveMethvin> well, we are putting the 1.x code in a new repo
[09:36:15] <DaveMethvin> new package
[09:36:16] <m_gol> once we settle on sth we can modify milestones
[09:36:30] <markelog> wow
[09:36:31] <DaveMethvin> so in some ways we ARE following semver
[09:36:37] <m_gol> DaveMethvin: I was thinking we could have dist/jquery.js, dist/jquery-legacy.js etc.
[09:36:41] <DaveMethvin> sorry, new PACKAGE
[09:36:50] <m_gol> but then we need src/ & src-legacy/ for AMD
[09:36:52] <markelog> ))
[09:36:53] <DaveMethvin> getting distracted here
[09:37:07] <gibson042> I like (jquery 1.11.x, jquery 2.1.x) → (jquery-compat 3.0.0, jquery 3.0.0)
[09:37:14] <m_gol> yeah, compat not legacy
[09:37:29] <markelog> oookay
[09:37:34] <markelog> confused (
[09:37:37] <m_gol> anyway, we'll need 2 packages, I guess, due to our build process, doing it in one package would be too high an overhead
[09:37:45] <m_gol> so I like what gibson042 says
[09:37:59] <markelog> jquery 1.11.1 ----> jquery-compat 1.12.0
[09:37:59] <markelog> jquery 2.1.1   ----> jquery 3.0.0
[09:38:00] <markelog> ?
[09:38:16] <DaveMethvin> yes
[09:38:22] <m_gol> markelog: that would require us to basically stop development on the IE8-compatible branch
[09:38:26] <markelog> or two jquery 3.0-something-or-another?
[09:38:31] <m_gol> so two jquery 3.0
[09:38:36] <m_gol> jquery 3.0 & jquery-compat 3.0
[09:38:42] <DaveMethvin> when the file is created that people include, what will the version be inside the file?
[09:38:57] <markelog> m_gol: that is not what Dave says?
[09:38:58] <gibson042> two distinct version- and API-synced packages
[09:38:59] <DaveMethvin> i just edited the notes to clarify my proposal
[09:39:02] <m_gol> 3.0.0, but we need to rename it consistently
[09:39:17] <DaveMethvin> if we use the same version it seems like that would be a lot more confusing
[09:39:23] <markelog> one is following semver the other is not?
[09:39:33] <m_gol> DaveMethvin: that would require us to revert the rAF patch & other things
[09:39:37] <DaveMethvin> jquery-compat follows semver
[09:39:42] <m_gol> I think we should switch to semver on both branches
[09:39:48] <m_gol> ah, that's what you mean
[09:40:05] <m_gol> dunno, I think it'd be easier to grok if versions matched between packages
[09:40:35] <m_gol> otherwise we'll need a major bump someday and we'll get jquery-compat 2.0 which people will mistake for jquery 2.0
[09:41:14] <m_gol> and jquery-compat 2.0 will be API-compatible with jquery 4.0
[09:41:14] <markelog> m_gol: right
[09:41:50] <markelog> i like two 3.x-something-or-another
[09:41:55] <m_gol> so I vote for matching versions
[09:42:01] <m_gol> markelog: what do you mean?
[09:42:06] <DaveMethvin> ok, 2 votes for matching versions
[09:42:22] <markelog> m_gol: gibson042 idea
[09:42:30] <m_gol> ok
[09:42:50] <m_gol> yeah, I've been pushing for that since Chicago ;)
[09:42:56] <m_gol> glad most agree :D
[09:42:57] <DaveMethvin> just a thought, how long do you think we'll be trying to keep these APIs totally synced? My thought is that we are at the very end of that effort
[09:43:20] <markelog> m_gol: sorry, i like m_gol idea! ))
[09:43:47] <m_gol> DaveMethvin: that depends on IE8 life time which in Europe is not used very often but America is somehow fond of this browser
[09:43:53] <m_gol> anyway, even if we stop soon, so what? :)
[09:43:56] <DaveMethvin> the reason there is a -compat is for older code and older browsers, so advanced apis won't even be able to appy there
[09:44:10] <DaveMethvin> just thinking about how we should view jquery-compat
[09:44:11] <markelog> new api's?
[09:44:19] <m_gol> we'll just leave it at 3.x then
[09:44:37] <markelog> is there interfaces that we can't support in compat?
[09:44:37] <m_gol> DaveMethvin: but we're trying to remain API compatible at least for now, right?
[09:44:40] <DaveMethvin> even $.xhr will have limits on older browsers unless we wrap the xhr object which i think we decided shoudln't be done
[09:45:04] <DaveMethvin> many of the complications of $.ajax come from having to wrap the xhr
[09:45:05] <m_gol> so I think we should keep the versions in sync as long as we're trying to be API-compatible
[09:45:16] <m_gol> DaveMethvin: sure, but that doesn't change our public API :)
[09:45:32] <m_gol> it does cause that this API will be close to unusable on IE8 but it will be the same
[09:45:41] <markelog> like XDomainRequest?
[09:45:42] <DaveMethvin> sure if that's your defn of api-compatible i'm all for it! :)
[09:45:46] <DaveMethvin> right markelog
[09:46:15] <DaveMethvin> without CORS and blob types for example on IE8
[09:46:15] <m_gol> XMLHttpRequest is not our API so our versions don't need to care about it :)
[09:46:25] <m_gol> as long as we're not doing sth special on it ourselves
[09:46:42] <gibson042> I'd even say it's allright for a method to exist in jquery but not jquery-compat, but what we DON'T want is a method in both places with a different signature
[09:46:51] <gibson042> (assuming identical package versions)
[09:46:52] <DaveMethvin> it's just that in the past we attempted to make everything work the same even if it needed thick wrappers at times or changes to the absractions
[09:46:55] <DaveMethvin> gibson042: agreed
[09:47:01] <DaveMethvin> ok
[09:47:20] <markelog> that maybe hard on jquery-migrate right?
[09:47:29] <m_gol> gibson042: I'd also say we don't want a method in -compat that is not present in the regular one
[09:47:38] <gibson042> m_gol right
[09:47:42] <m_gol> so that upgrade from -compat to jquery is relatively painless
[09:47:48] <m_gol> for people
[09:47:49] <DaveMethvin> i have a few things i'd like to do to migrate anyway, but yes it can only be so heroic
[09:47:58] <DaveMethvin> so it sounded like the voting was for version numbers synchronized on both packages?
[09:48:14] <m_gol> 3 votes for that one from what I see :)
[09:48:19] <markelog> timmywil: ?
[09:48:45] <DaveMethvin> so how will the version numbers be shown in the built file? how about the actual file names on the CDN?
[09:48:46] <timmywil> I guess I'd lean twoards proposal 1
[09:48:55] <DaveMethvin> haha
[09:49:15] <ryanneufeld> has the argument been made that having the same versions for both makes it very easy to implement? All you need is matching versions, and you know it's gonna work
[09:49:18] <ryanneufeld> ?
[09:49:20] <DaveMethvin> i think gibson042 was for synced version numbers?
[09:49:24] <gibson042> yes
[09:49:29] <DaveMethvin> right that's the benefit
[09:49:33] <m_gol> ryanneufeld: yes, that's my thinking
[09:49:44] <DaveMethvin> the confusion comes in that now the version doesn't indicate anything about the browser support
[09:49:58] <ryanneufeld> as a non-core-dev-but-implementer that's what i'd like
[09:50:05] <DaveMethvin> but if we can figure how to name the releases and files on the cdn....
[09:50:24] <m_gol> DaveMethvin: ideally CDNs will create a separate jquery-compat package for us
[09:50:39] <m_gol> that should be the easiest course of action
[09:50:43] <DaveMethvin> so i'd include jquery-compat-3.0.0.min.js ?
[09:50:47] <m_gol> yup
[09:50:49] <DaveMethvin> sounds like it works
[09:51:25] <timmywil> that works with the other proposal too
[09:51:30] <DaveMethvin> yes it does
[09:51:43] <DaveMethvin> just that we're making a breaking change with promise/a
[09:51:46] <m_gol> and https://ajax.googleapis.com/ajax/libs/jquery-compat/3.0.0/jquery-compat.min.js
[09:52:26] <m_gol> cc paul_irish ^
[09:52:27] <DaveMethvin> so the concern was whether we keep the linear version numbering (despite semver) or start at a new number
[09:52:46] <DaveMethvin> since we are putting jquery-compat in a new repo we can do either
[09:53:06] <DaveMethvin> but if the version number indicates api level then I guess it does make sense for the two to have the same version
[09:53:12] <m_gol> we technically don't need to follow semver between jquery@1.11.1 and jquery-compat@1.12.0, I just think it's going to be confusing
[09:53:13] <timmywil> I guess it could be confusing when the time comes to bump jquery-compat
[09:53:15] <DaveMethvin> at least that's what i have been convinced ov here
[09:53:29] <m_gol> :)
[09:53:42] <DaveMethvin> from history it always seems we end up bumping both, even tho some bugs only happen in one
[09:53:46] <timmywil> jquery-compat 2.0 would be nothing like jquery 2.0
[09:54:00] <DaveMethvin> code wise, no but public api would be the same
[09:54:14] <DaveMethvin> oh you mean if you started at 1.12
[09:54:15] <DaveMethvin> yes
[09:54:21] <DaveMethvin> that is a downside of starting at 1.12
[09:54:26] <m_gol> yeah, that's what I said above :)
[09:54:35] <timmywil> ok, I'm fine with 3.0 then
[09:54:38] <DaveMethvin> so maybe the version number should only indicate apis
[09:54:54] <m_gol> that's semvery
[09:55:05] <timmywil> but I'd like to start following semver with both packages
[09:55:07] <DaveMethvin> and the -compat lets people know it's handling a lot more different browsers
[09:55:10] <DaveMethvin> ok
[09:55:50] <DaveMethvin> perfect
[09:56:02] <DaveMethvin> so anything else we should discuss
[09:56:18] <DaveMethvin> global warming? the palestinian conflict? we have 5 minutes folks
[09:56:43] <m_gol> DaveMethvin: we should contact CDN people before we do all that, they may need time
[09:57:02] <DaveMethvin> yeah i think we need a blog post
[09:57:02] <gibson042> and probably get a blog post up
[09:57:09] <DaveMethvin> i will draft one and send to jquery-devs-team
[09:57:39] <DaveMethvin> alrighty then, sounds like we're done
[09:57:42] <DaveMethvin> thanks guys!