[09:00:11] <DaveMethvin> hey everyone!
[09:00:44] <DaveMethvin> i'm in a conference on the west coast but it hasn't started so i'm going to multitask :)
[09:00:57] <DaveMethvin> looks like gibson042 markelog  ... anyone else?
[09:01:02] <DaveMethvin> timmywil m_gol
[09:01:05] <markelog> hey-hey
[09:01:13] <timmywil> hi
[09:01:35] <DaveMethvin> all these time zone changes, soooo confusing
[09:01:46] <DaveMethvin> we should all go to moscow time
[09:02:26] <markelog> :-)
[09:02:41] <markelog> that would be weird
[09:02:54] <DaveMethvin> so thanks for getting some stuff done last week
[09:03:10] <DaveMethvin> i've been traveling and doing so many other things i haven't gotten the chance to even organize this
[09:03:31] <m_gol> present
[09:04:03] <DaveMethvin> so  someone suggested we have a wontfix tag, i'm good with that, are there any others we should have that are similar to the trac resolution?
[09:04:08] <timmywil> you know what, I don't think we need to wait to land PRs before renaming 1.x-master
[09:04:21] <timmywil> since we don't use the merge button
[09:04:37] <DaveMethvin> oh yeah, i guess that's true
[09:04:50] <DaveMethvin> if we rebase it should take care of it and not be confused
[09:04:55] <m_gol> timmywil: we need to wait before *deleting* the 1.x-master branch, though
[09:05:09] <m_gol> otherwise all those PRs get auto-closed
[09:05:23] <m_gol> DaveMethvin: "so  someone suggested we have a wontfix tag" - that would be me ;)
[09:05:23] <timmywil> orly?
[09:05:32] <timmywil> that makes sense
[09:05:40] <DaveMethvin> yeah i couldn't remember m_gol  thanks
[09:05:41] <timmywil> +1 wontfix
[09:05:50] <DaveMethvin> any others we should use?
[09:05:56] <DaveMethvin> cantfix?
[09:06:03] <timmywil> needs review has been helpful in Sizzle
[09:06:07] <m_gol> but good point, we can just create a new branch pointing to 1.x-master and just freeze 1.x-master where it is until we close all PRs
[09:06:16] <m_gol> there are about 4 of them targetting 1.x-master :D
[09:06:19] <m_gol> not a huge deal
[09:06:22] <timmywil> to tag the ones that could use more immediate attention
[09:06:25] <DaveMethvin> yeah we have needs info which is similar?
[09:06:37] <timmywil> I assumed needs info was more like "pending"
[09:06:42] <m_gol> needs info is waiting for info from the reporter
[09:06:50] <m_gol> needs review is info from us :)
[09:06:51] <DaveMethvin> it can mean whatever we want it to mean! :)
[09:06:52] <timmywil> needs review needs input from the team
[09:07:02] <timmywil> well, that's what I think it means
[09:07:07] <m_gol> yup
[09:07:12] <DaveMethvin> sure tho, needs review makes it clearer that the team needs to do something
[09:07:13] <DaveMethvin> which is good
[09:07:29] <DaveMethvin> ok so needs review
[09:08:29] <timmywil> I'm fine without notabug. Closing the issue without a fix pretty much says that. Unless it is a feature that we don't want to include, in which case we'd tag it wontfix.
[09:08:42] <markelog> usually that label is needed if pr needs 2 (or something) people from the team to agree on landing it
[09:09:01] <DaveMethvin> and as long as we are good at assigning them to milestones it should be easy to tell what's junk and what's not
[09:09:09] <DaveMethvin> using their filters
[09:09:28] <timmywil> no need for "fixed" either. Closing with a commit says that.
[09:09:39] <DaveMethvin> yep
[09:10:06] <timmywil> Also, issues should get milestones when accepted.
[09:10:23] <DaveMethvin> good practice
[09:10:45] <DaveMethvin> we need some bots to review things and complain when something is wrong :)
[09:10:47] <timmywil> would anyone object if I create the compat branch right now?
[09:10:50] <markelog> and if don't have milestone yet?
[09:10:53] <timmywil> without deleting 1.x yet
[09:10:55] <markelog> the next one?
[09:11:43] <m_gol> timmywil: go for it :)
[09:11:56] <markelog> how could we assign milestone if it doesn't exist yet?
[09:12:18] <timmywil> trac practice was to include it in the upcoming milestone or 1.next, but we can be more specific than that
[09:12:32] <DaveMethvin> i think we could have a bot to be sure nothing is in a bad state, like closed with a pr but no milestone
[09:12:33] <markelog> how?
[09:12:47] <timmywil> by not assigning a milestone until you know which version it will be in
[09:13:07] <markelog> you said "it's not accepted" without milestone
[09:13:23] <markelog> what is that mean?
[09:13:29] <timmywil> s/accepted/assigned
[09:13:37] <DaveMethvin> ah, assigned would work fine
[09:13:44] <timmywil> if you're about to fix it, set a milestone
[09:14:10] <markelog> and if there isn't next milestone, i should created it?
[09:14:44] <m_gol> yes, preferrably
[09:14:48] <timmywil> sure
[09:14:55] <m_gol> it doesn't happen extremely often ;(
[09:14:57] <m_gol> * ;)
[09:15:04] <DaveMethvin> i'm sure we'll have to make a few more rules here and there, that's no problem
[09:15:12] <markelog> well, right after the release, we will have this situation
[09:15:14] <DaveMethvin> gh issues is a lot more free form
[09:15:16] <m_gol> btw, how we should label/assign/set milestones on PRs (not issues)?
[09:15:31] <timmywil> the usual flow will be to assign it to yourself, set milestone to the upcoming verison, commit a fix
[09:16:01] <m_gol> it seems duplicating stuff when there's an issue and a PR fixing it to duplicate labels etc. on both
[09:16:24] <markelog> it's annoying yeah
[09:16:26] <m_gol> OTH, sometimes people report an issue+PR in one go, GitHub seems to encourage that a little
[09:16:41] <DaveMethvin> so usually when creating the changelog the PRs will be what we want to look at, right
[09:16:42] <DaveMethvin> ?
[09:16:53] <m_gol> DaveMethvin: not only
[09:17:03] <m_gol> a PR may fix an issue in a way that doesn't directly point to the problem
[09:17:07] <timmywil> maybe we just need to set both
[09:17:22] <DaveMethvin> or one patch covers multiple issues, or the other way around, yeah
[09:17:25] <m_gol> e.g. we can have an issue "IE crashes on location change" and a fix would be "cache the document on use of a foobar"
[09:17:35] <m_gol> so it makes sense to point to what has actually been fixed
[09:17:48] <timmywil> meaning associate the PR and issue with the milestone. I don't think syncing the labels is as important
[09:18:05] <m_gol> k, we might not use labels on PRs at all
[09:18:10] <DaveMethvin> yeah, the milestone is the most important on the PR i think
[09:18:22] <m_gol> perhaps we could require folks to create an issue before submitting a PR if that PR is fixing sth?
[09:18:44] <m_gol> otherwise if we find the PR wrong, we have to close it and there's no way to just preserve "the issue part"
[09:19:05] <timmywil> I always include both when amending the commit message. So worse comes to worse, they are at least referenced in the commit.
[09:19:10] <DaveMethvin> in that case we'd definitely need to create the issue
[09:19:38] <DaveMethvin> we don't and shouldn't get a bunch of "out of the blue" PRs with no corresponding issue
[09:19:54] <m_gol> yes, so we require to have an issue created first, right?
[09:19:55] <DaveMethvin> except for those "fix a typo" ones where people want to be in the AUTHORS file
[09:20:07] <DaveMethvin> I'd be fine with that rule
[09:20:10] <m_gol> people conflate issues with PRs all the time on GitHub but we need to distinguish them
[09:20:18] <m_gol> DaveMethvin: yeah, those micro ones can stay
[09:20:45] <markelog> So PR almst always should be linked to the issue
[09:20:46] <m_gol> DaveMethvin: I've seen you usually introduce the changes yourself with the shout out to the reporter but not marking them as commit author
[09:21:02] <m_gol> DaveMethvin: on those typos PR & similarly trivial stuff
[09:21:02] <DaveMethvin> yes, generally those are ones where they are trivial
[09:21:06] <DaveMethvin> yeah
[09:21:12] <markelog> we should make sure original issue is linked to every PR it had
[09:21:39] <markelog> so if you would find an issue you could find all the attempts to fix it
[09:21:50] <DaveMethvin> yes
[09:22:01] <m_gol> markelog: this will happen more or less automatically, thoguh
[09:22:03] <m_gol> * though
[09:22:07] <DaveMethvin> it should i'd think
[09:22:12] <DaveMethvin> the issue will have refs to the PRs
[09:22:16] <m_gol> if sb submits a PR, they usually mention the issue they fix ;)
[09:22:24] <m_gol> and that gets auto-referenced back by GitHub
[09:22:25] <markelog> if developer would link them, yes, but sometimes they don't, then we should do that
[09:22:35] <DaveMethvin> if not we can make a reference in the comments
[09:22:48] <markelog> execatly
[09:22:55] <markelog> exactly
[09:22:59] <DaveMethvin> ok so it sounds like we have a plan for PRs and issues
[09:23:10] <m_gol> so let's not merge anything else to 1.x-master from now on
[09:23:20] <m_gol> this branch needs to die once we handle all those 4 remaining PRs
[09:23:25] <m_gol> (there are exactly 4)
[09:23:39] <markelog> we should send a letter about this i guess
[09:23:42] <DaveMethvin> can they be landed? is anything holding them up?
[09:23:50] <markelog> so people how is not present would know about it
[09:24:26] <DaveMethvin> the sooner we can merge them and remove the 1.x-master branch the easier it will be to prevent people from making PRs against it! :)
[09:24:45] <markelog> right
[09:25:08] <m_gol> I pasted links on the doc
[09:26:01] <m_gol> one is by gibson042, he can always move it
[09:26:43] <gibson042> ah yeah, no problem on that
[09:26:53] <gibson042> that's the one that needs a Sizzle change
[09:26:56] <DaveMethvin> i have about 5 minutes before i have to move to another meeting
[09:27:00] <DaveMethvin> sorry about that
[09:27:30] <DaveMethvin> i'd really like to see us land some more of this stuff, sorry i haven't been doing more on it myself
[09:28:35] <DaveMethvin> are there any things blocking us on getting more of this landed?
[09:28:56] <m_gol> I'll need to look into it
[09:29:03] <m_gol> btw, what about my PR dropping older browsers?
[09:29:09] <DaveMethvin> that one looked good to me
[09:29:15] <m_gol> any additional remarks now that I stopped actively dropping Phantom? ;)
[09:29:44] <markelog>  phantom is pain
[09:29:51] <DaveMethvin> obviously i'm not the only one who doesn't like it :)
[09:29:59] <markelog> from some perspective
[09:30:08] <m_gol> I really think UI & Mobile should work on getting rid of it from their stack
[09:30:19] <markelog> not that easy
[09:30:27] <markelog> if it were no one would use it
[09:30:36] <DaveMethvin> all phantom tells you is that there are no js errors if you were writing js for a browser that was 7 or 8 years old :)
[09:30:45] <markelog> smoke tests
[09:30:48] <DaveMethvin> right
[09:30:52] <markelog> that is what it is
[09:31:03] <DaveMethvin> jshint gets you pretty close to what phantom does :))
[09:31:04] <m_gol> you test if it doesn't smoke the browser
[09:31:10] <m_gol> the rest is left untested
[09:31:15] <m_gol> :)
[09:31:21] <markelog> )
[09:31:39] <DaveMethvin> alright, sorry guys but i have to go
[09:31:42] <m_gol> k
[09:31:50] <markelog> see ya!
[09:31:51] <DaveMethvin> thanks for keeping things going