[09:02:39] <DaveMethvin> whoops
[09:02:41] <DaveMethvin> it's meeting time!
[09:02:50] <m_gol> present
[09:03:33] <gibson042> here
[09:04:00] <markelog__> hey-hey
[09:04:08] <DaveMethvin> cool
[09:04:28] <DaveMethvin> timmywil doesn't seem to be online
[09:04:40] <DaveMethvin> okay
[09:04:49] <DaveMethvin> so we got a lot done recently!
[09:04:57] <DaveMethvin> which is awesome
[09:05:10] <DaveMethvin> since we have to ship 3.0 at SOME point :)
[09:05:30] <DaveMethvin> first thing i wanted to ask was whether we need to accelerate a patch release for that Safari bug
[09:05:40] <DaveMethvin> if it's important enough to patch it seems like waiting for 3.0 isn't good
[09:05:52] <DaveMethvin> esp since that release will have some breaking changes
[09:06:16] <m_gol> DaveMethvin: that might be a good idea
[09:06:25] <m_gol> we should branch before any breaking changes were made, though
[09:06:36] <DaveMethvin> gibson042: are there any breaking/behavior changes in sizzle master that we would need to avoid
[09:06:42] <m_gol> though then what timmywil said about size reduction wouldn't be true
[09:06:51] <m_gol> he wanted to batch this change with dropping support for some browsers
[09:06:52] <markelog__> hm, doesn't seem as a significant bug
[09:07:15] <gibson042> yes, but we'll handle them the same as jQuery: new commits against the parent of the last release
[09:07:29] <DaveMethvin> well looking at a realistic timeline, most people wouldn't get the Safari patch, period
[09:07:36] <markelog__> at least no one noticed it, except for us
[09:07:56] <DaveMethvin> b/c people will hold back with 3.0 since its a major release
[09:08:05] <DaveMethvin> regardless of how breaking it really is
[09:08:50] <DaveMethvin> i just wonder if safari will put out a patch before or shortly after we get 3.0 out the door
[09:09:37] <markelog__> as i understand they don't have a clear release cycle
[09:09:48] <DaveMethvin> certainly not clear to US :)
[09:09:53] <markelog__> so it might be soon or who knows
[09:10:01] <DaveMethvin> and we have no contacts there
[09:10:10] <markelog__> (
[09:10:14] <DaveMethvin> they're not open at all about what they are doing
[09:10:39] <m_gol> I wonder if we should get a little more aggressive about that
[09:10:50] <m_gol> and to communicate clearly that Apple is behaving in an anti-developer way
[09:10:54] <markelog__> like storm in the apple office?
[09:11:00] <DaveMethvin> well i did want to do a blog post, lol
[09:11:15] <m_gol> this is pretty ridiculous
[09:11:37] <m_gol> apparently information if they're going to fix it or not is an important feature to be announced at WWDC
[09:11:38] <m_gol> or sth
[09:11:48] <m_gol> or otherwise I see no reason why it has to be so secret
[09:11:58] <DaveMethvin> this is they way microsoft used to be
[09:12:02] <DaveMethvin> so glad they opened up
[09:12:05] <markelog__> i think if they would be open they would have to tell about their plans, which is not an apple thing
[09:12:14] <m_gol> but that's what you get, every Apple employee will tell you explicitely that they are not allowed to talk about upcoming products in any way
[09:12:20] <DaveMethvin> right
[09:12:23] <DaveMethvin> or be fired
[09:12:32] <m_gol> It's a blessing WebKit was forked from KHTML, otherwise we wouldn't even know what's happening there
[09:12:50] <DaveMethvin> right, we can see it's fixed in WK but have no idea when Safari will pull it in
[09:13:05] <DaveMethvin> also we get to see the scope of the bug which is fortunate
[09:13:13] <m_gol> at this point I feel we should put more pressure on Apple
[09:13:24] <markelog__> sounds awesome :-)
[09:13:25] <m_gol> if enough people will publicly complain maybe they'll start feeling it
[09:13:27] <DaveMethvin> i can do that via a blog post for sure
[09:13:52] <DaveMethvin> if we think this is a bug that they should fix though, doing a 1.12/2.2 would make it clear
[09:13:58] <markelog__> always wanted to put pressure on those guys and didn't even know it )
[09:14:10] <DaveMethvin> otherwise this patch won't  make it into jquery for another month or two
[09:14:14] <markelog__> can we also ask them to release new thunderbolt display?
[09:14:17] <DaveMethvin> and won't be adopted for even longer
[09:14:20] <DaveMethvin> lol
[09:14:46] <markelog__> )
[09:15:51] <DaveMethvin> so, patch release or not? like i say it would help make the point for the blog post
[09:16:00] <m_gol> I'm +1 on that
[09:16:19] <DaveMethvin> no doubt that some of this is political as much as technical
[09:16:36] <DaveMethvin> we need apple to communicate with us!
[09:16:51] <markelog__> sure, if it helps
[09:17:04] <m_gol> it looks so weird
[09:17:13] <m_gol> when we talk with an Apple employee in the ticket
[09:17:25] <m_gol> and yet we still speculate if the fix is going to be backported or not
[09:17:37] <m_gol> even though the employee probably already knows the answer
[09:17:44] <DaveMethvin> for all we know he's been banished for talking to the enemy
[09:17:59] <DaveMethvin> if we do a 1.12/2.2 i think that can happen quickly ... basically start from 1.11.1/2.1.1 and apply the patch
[09:18:38] <DaveMethvin> gibson042: what is your take? patch release or not?
[09:19:45] <DaveMethvin> well let's talk 3.0 in the meantime
[09:19:55] <m_gol> we might want to branch from https://github.com/jquery/jquery/commit/e488d985cfb10ab8c684bbc6a9b8ff3eae23bf83
[09:19:57] <m_gol> not from 2.1.1
[09:20:09] <m_gol> I'll need to check but AFAIK there were no breaking changes before that commit
[09:20:20] <m_gol> and it might be useful to get this patch in
[09:20:38] <DaveMethvin> also want to be sure we're not putting in any higher risk patches, but we can check that m_gol
[09:20:49] <m_gol> the next commit is changing globalEval so this is definitely the last possible ne
[09:21:00] <m_gol> * the last possible one
[09:21:25] <gibson042> on the Sizzle front, I'd be checking https://github.com/jquery/sizzle/compare/2.0.0...master for anything that makes sense in a 2.1.0
[09:21:46] <gibson042> and cherry-picking into a new branch for fast-track release
[09:22:25] <DaveMethvin> i'm good with pulling in anything that is low risk and high reward
[09:22:41] <DaveMethvin> that focuses the 3.0 release as well
[09:22:44] <m_gol> DaveMethvin: so you think 2.2.0 and not 2.1.2?
[09:23:00] <DaveMethvin> i guess it depends on what's in it :)
[09:23:04] <m_gol> :)
[09:23:05] <gibson042> for jQuery? probably 2.1.2
[09:23:19] <m_gol> we probably shouldn't introduce any breaking changes in 2.2.0 anyway because semver
[09:23:23] <DaveMethvin> it *should* be just patches yes
[09:23:24] <gibson042> unless there's something that adds functionality
[09:23:25] <m_gol> and so far we used patch releases
[09:23:33] <m_gol> right
[09:23:51] <DaveMethvin> i think we should hold off on functionality and even some bug fixes that might change behavior in unexpected ways
[09:24:03] <DaveMethvin> like our wrapAll one, wouldn't want that in there
[09:24:34] <DaveMethvin> ok, so the answer for a patch release is "yes" ?
[09:25:02] <gibson042> looks that way
[09:25:06] <m_gol> so for Core it's https://github.com/jquery/jquery/compare/2.1.1...e488d985cfb10ab8c684bbc6a9b8ff3eae23bf83
[09:25:14] <markelog__> wow, just checking last commits on m_gol link, it seems i'm resposible for a lot of behaviour change commits, i guess i will have some rotten apples from some people for 3.0
[09:25:23] <m_gol> most of that are build changes and 1 or 2 fixes
[09:25:39] <markelog__> DaveMethvin: yep
[09:25:45] <DaveMethvin> m_gol can you create the jquery fork, and gibson042 the sizzle one?  when in doubt, leave it out
[09:25:58] <DaveMethvin> oh boy the changelog on this will be fun
[09:26:18] <gibson042> so it looks like we're landing https://github.com/jquery/sizzle/pull/297 as-is, then? I was hoping someone would find a way to reduce it
[09:26:24] <m_gol> DaveMethvin: fork? you mean a branch?
[09:26:30] <DaveMethvin> yeah branch, sorry
[09:26:55] <m_gol> gibson042: we may still try to reduce it in the next couple of days
[09:26:55] <markelog__> gibson042: i could check it out
[09:27:06] <m_gol> gibsn042: though I guess you've already compressed it :)
[09:27:10] <DaveMethvin> gibson042: it's big for sure ... yeah see what you can do but otherwise it could land as-is
[09:27:33] <m_gol> DaveMethvin: what's the name of the branches? 2.1-stable & 1.11-stable?
[09:27:47] <m_gol> (assuming we'll go for 2.1.2 & 1.11.2)
[09:27:56] <markelog__> although 30 bytes doesn't seem that Big
[09:28:03] <DaveMethvin> m_gol: worksforme
[09:28:12] <m_gol> k
[09:28:39] <DaveMethvin> alrighty then ... 3.0?
[09:28:59] <m_gol> there is my largish PR
[09:29:04] <m_gol> with dropping older browsers
[09:29:14] <DaveMethvin> and i agree we should land that soon before it goes stale
[09:29:18] <m_gol> any further remarks? I'd like to land it today, rebasing such a monster can be painful
[09:29:29] <m_gol> It's currently rebased over latest compat, though
[09:29:42] <DaveMethvin> i am okay with it
[09:29:49] <m_gol> I'll need little followup PRs for master, since some of the comments apply there as well
[09:30:04] <DaveMethvin> i did want to make sure we had an issue filed for all the changes it implies for browser support
[09:30:14] <DaveMethvin> to make the changelog document better
[09:30:42] <m_gol> DaveMethvin: like https://github.com/jquery/jquery/issues/1836? ;)
[09:31:03] <m_gol> I can update the description to mention specifically what's being dropped
[09:31:12] <DaveMethvin> yeah that would be great
[09:31:13] <m_gol> is the title OK or should it contain the list as well?
[09:31:36] <DaveMethvin> i think the title can stay generic
[09:31:45] <DaveMethvin> i'd just have the description mention the dropped browsers
[09:32:05] <m_gol> k
[09:32:42] <m_gol> I'd like to land https://github.com/jquery/jquery/pull/1901 as well
[09:33:03] <DaveMethvin> objections?
[09:33:45] <DaveMethvin> silence is golden
[09:33:47] <m_gol> :)
[09:33:49] <markelog__> oh, can you give me an hour to check it out?
[09:33:52] <m_gol> sure
[09:33:58] <markelog__> i'm typing pretty slow )
[09:34:13] <m_gol> I can land them tomorrow morning if you want to look at it today
[09:34:15] <DaveMethvin> okay then 3.0
[09:34:28] <m_gol> markelog__: you mean both PRs? this one for dropping browsers as well?
[09:34:40] <markelog__> sure why not )
[09:34:55] <m_gol> k
[09:35:10] <m_gol> DaveMethvin: ok, 3.0 ;)
[09:35:20] <DaveMethvin> yeah
[09:35:51] <DaveMethvin> given what's open could we potentially make a mid-January release?
[09:36:14] <DaveMethvin> usually that's been when we do a "state of jQuery" thing and other announcements
[09:36:22] <DaveMethvin> at the very least a stable beta then
[09:36:40] <markelog__> sounds good
[09:36:44] <gibson042> +1
[09:36:51] <m_gol> k
[09:37:11] <DaveMethvin> we can firm it up as it gets closer
[09:38:38] <DaveMethvin> oh on the patch release, can we have that ready by next Monday?
[09:38:45] <DaveMethvin> it's probably not too hard to get ready
[09:38:55] <gibson042> I don't foresee any problems with that
[09:39:01] <m_gol> seems fine
[09:39:16] <DaveMethvin> hardest part is probably re-tagging tickets :)
[09:39:39] <m_gol> ha, right
[09:39:43] <DaveMethvin> I'll skip the style guide discussion, we've got that going on fine in the issue
[09:40:09] <DaveMethvin> i just wanted to see if we all agreed on the approach for PRs and issues
[09:40:51] <DaveMethvin> the issues are for making the functional list of changes, and the PRs and commits have more detail
[09:40:59] <DaveMethvin> but more detail than you typically want in a changelog
[09:41:41] <m_gol> the problem is that people often submit a "prissue"
[09:41:54] <m_gol> should we ask them to create a real issue then?
[09:41:59] <DaveMethvin> yeah i think so
[09:42:08] <DaveMethvin> or we can even do it after the fact
[09:42:17] <markelog__> that is what we did before with trac
[09:42:21] <DaveMethvin> as long as the issues end up capturing all the important changes
[09:42:36] <gibson042> it was necessary with track, but is it now that issues and PRs are in one place?
[09:42:59] <gibson042> sometimes, the PR is essentially self-documenting
[09:43:02] <m_gol> gibson042: what if the problem is real but the PR that "fixes" it is wrong?
[09:43:07] <m_gol> then we have to close the PR
[09:43:08] <DaveMethvin> the prissue thing is pretty rare tho
[09:43:20] <m_gol> but if we treat it the same as the issue, we then close the issue as well, effectively
[09:43:24] <DaveMethvin> i'm just thinking of how we'll do a changelog
[09:43:30] <m_gol> yeah, that as well
[09:43:34] <DaveMethvin> usually there is both a pr and an issue
[09:43:39] <gibson042> DaveMethvin: exactly, changelog generation I think is the key
[09:43:40] <DaveMethvin> so you don't want both logged
[09:43:42] <markelog__> then, we could close the PR and open an issue?
[09:43:50] <gibson042> markelog__: +1
[09:44:18] <m_gol> so we'll need a way to filter out PRs that have associated issues
[09:44:23] <markelog__> it seems it's github intention to not divide those
[09:44:31] <DaveMethvin> well that's the beauty of always having an issue :)
[09:44:41] <m_gol> markelog__: well, now they are separated
[09:44:48] <DaveMethvin> also for cases where a PR fixes two issues etc
[09:44:49] <m_gol> if you go to issues you won't find PRs
[09:45:00] <markelog__> yeah, but not really
[09:45:00] <m_gol> unless you manually edit the "is:issue" out
[09:45:07] <markelog__> exactly
[09:45:30] <DaveMethvin> yeah the way gh treats these make it more complex than it should be
[09:45:38] <m_gol> they share the numbering, though and issues/PR_NUMBER redirects to pull/PR_NUMBER
[09:45:48] <DaveMethvin> but that's why i wanted to simplfy by always having an issue for each logical problem
[09:45:56] <arthurvr> there is a chrome extension for that I believe
[09:45:57] <markelog__> i really don't know if we should or shouldn't do that
[09:46:18] <markelog__> at least, we divide them with "Closes" and "Fixes"
[09:46:18] <DaveMethvin> mainly i want some way to query the GH API to create the changelog
[09:46:33] <DaveMethvin> we do but that requires scanning the log messages
[09:46:48] <markelog__> we probably should check out how other projects are doing that
[09:47:00] <DaveMethvin> good point markelog__
[09:47:03] <DaveMethvin> i will do that
[09:47:20] <m_gol> I think other projects often generate changelog from commits and not issues/PRs
[09:47:54] <DaveMethvin> well they SUCK then :)
[09:47:58] <m_gol> Angular uses https://github.com/btford/grunt-conventional-changelog
[09:48:33] <m_gol> the resulting CHANGELOG.md file: https://github.com/angular/angular.js/blob/master/CHANGELOG.md
[09:48:58] <m_gol> links to issues are appended to changelog entries but only links
[09:49:09] <DaveMethvin> okay well i'll look at that, better to use something we can easily integrate
[09:49:33] <m_gol> they have a different commit format, though, so we wouldn't be able to use it directly
[09:49:37] <DaveMethvin> i just worry that we have a lot of commits that are more housekeeping and not really relevant to external users
[09:49:52] <DaveMethvin> those will clutter the changelog
[09:50:00] <m_gol> like "fix($browser): prevent infinite digests when clearing the hash of a url"
[09:50:20] <m_gol> yeah, they use "chore(COMPONENT):" for those ones
[09:50:20] <DaveMethvin> yeah, the commit format could help that
[09:50:47] <DaveMethvin> looks like it's time to make a change to commitplease :)
[09:51:10] <m_gol> I'm not sure if Scott would love another commit format change :P
[09:51:56] <DaveMethvin> it would definitley be nice to have this be smoothly automated and not have too much noise
[09:52:16] <DaveMethvin> okay, specific issues
[09:52:42] <DaveMethvin> i am good with the gibson042 suggestion to move that junk to Migrate
[09:52:55] <DaveMethvin> i'd totally forgotten about that older PR
[09:53:04] <m_gol> if that doesn't require 5 KB of code then I agree it's better
[09:53:09] <m_gol> to not keep this cruft
[09:53:17] <scott_gonzalez> This is really not a difficult thing.
[09:53:23] <DaveMethvin> i don't mind Migrate getting big
[09:53:31] <scott_gonzalez> Generating a changelog by ignoring PRs is super simple.
[09:53:41] <scott_gonzalez> And it'd be fantatic if someone would finally address this in jquery-release.
[09:53:47] <scott_gonzalez> Since I"ve been waiting forever on that.
[09:54:07] <scott_gonzalez> It's literally the oldest issue: https://github.com/jquery/jquery-release/issues/1
[09:54:46] <m_gol> scott_gonzalez: yeah, but markelog__ & gibson042 suggested to sometimes treat PRs as issues
[09:54:52] <scott_gonzalez> Please don't.
[09:55:07] <scott_gonzalez> It makes everything so much more confusing.
[09:55:17] <gibson042> I think changelog generation is more important
[09:55:26] <gibson042> if prissues complicate it, then to hell with them
[09:55:27] <DaveMethvin> it's worth looking at what others do first
[09:55:38] <DaveMethvin> i've got it as an issue for me to look at
[09:55:44] <m_gol> I agree with scott_gonzalez but we can research first
[09:56:23] <DaveMethvin> okay, next is that rsLeft question
[09:56:34] <DaveMethvin> it does look like that's an Opera 11-era quirk
[09:56:42] <DaveMethvin> that we can remove
[09:56:58] <DaveMethvin> so i'll leave the issue open
[09:57:21] <DaveMethvin> i wonder how many others are like that, lacking enough docs or a //Support comment
[09:57:46] <m_gol> I've found a couple while removing code for compat ;)
[09:57:56] <m_gol> some even concern `master`
[09:58:10] <DaveMethvin> okay, any other critical issues? i'm way happy with our progress lately!
[09:58:18] <m_gol> some are because MS fixed an IE10/IE11 bug but the support comment stayed, obviouslu
[09:58:21] <m_gol> * obviously
[09:58:39] <m_gol> what about Promises/A+ compat?
[09:58:47] <DaveMethvin> ok, let's call it a meeting then
[09:58:51] <DaveMethvin> oh
[09:58:52] <m_gol> https://github.com/jquery/jquery/pull/1821
[09:58:52] <DaveMethvin> wait
[09:58:55] <DaveMethvin> yeah
[09:58:58] <gibson042> aargh, we are out of time
[09:59:21] <DaveMethvin> saved by the bell!!!
[09:59:22] <gibson042> my two points are 1) are we keeping .pipe, and 2) are we breaking more than just .then
[09:59:22] <DaveMethvin> :)
[09:59:42] <gibson042> there's more nuance, but those are the major ones
[10:00:07] <DaveMethvin> gibson042: i think we agreed on keeping pipe
[10:00:29] <DaveMethvin> and for the second the question was whether mixed then/done worked?
[10:00:42] <gibson042> also dfd.resove( thenable )
[10:00:51] <m_gol> if we keep Deferred as kinda deprecated a little as a whole then probably it's not worth removing pipe completely
[10:01:26] <gibson042> ok; I really have to bail
[10:01:30] <m_gol> dfd.resolve( thenable ) is specified in Promises/A+, right?
[10:01:32] <gibson042> can this happen in -dev and on the PR?
[10:01:37] <m_gol> I guess we can discuss it in a week
[10:01:40] <gibson042> no
[10:01:50] <gibson042> .resolve is not in the spec
[10:01:54] <DaveMethvin> ok we can also do async in the ticket
[10:01:56] <gibson042> yes to "discuss in a week", though
[10:02:00] <m_gol> :)
[10:02:03] <markelog__> )
[10:02:03] <DaveMethvin> alright
[10:02:08] <DaveMethvin> so let's call it a meeting now
[10:02:11] <m_gol> k