[09:00:41] <rwaldron> Here
[09:00:42] <bot-t> (15 hours 50 mins ago) <danheberden> tell rwaldron I hope rose like's her surprise dude! You're crafty!
[09:00:51] <rwaldron> hey DaveMethvin
[09:00:54] <rwaldron> hey jrburke
[09:00:56] <DaveMethvin> imma coiming!
[09:00:57] <JohnResig> hey all
[09:01:00] <DaveMethvin> hey
[09:01:09] <jrburke> Hi rwaldron
[09:01:09] <bot-t> (286 hours ago) <jaubourg> tell jrburke nice to see you around anyway ;)
[09:01:38] <rwaldron> hey JohnResig
[09:02:28] <DaveMethvin> so i put a few topics on the agenda...just looking at the schedule and thinking the conf is coming really soon now
[09:03:03] <JohnResig> yeah, we're just over a month away
[09:04:48] <ajpiano> seems like we should probably re-discuss rAF
[09:05:08] <rwaldron> hahaha
[09:05:12] <rwaldron> i was waiting for that
[09:05:17] <rwaldron> it was tooooo quiet
[09:05:20] <gnarf> heh
[09:06:00] <DaveMethvin> well we have that really nice thread in the forum that lays out the points nicely
[09:06:29] <JohnResig> yeah, I agree with those that wanted to back this out
[09:06:46] <ajpiano> are we going to be putting it back in though?
[09:06:57] <JohnResig> we changed the behavior in 1.6, it caused an unforseen regression, we need to back it out until we can make it not cause regressions
[09:07:31] <DaveMethvin> we could leave it in and control whether we use it with a flag, that's not hard to do
[09:07:31] <JohnResig> thankfully users probably won't have to wait too long (~1 month)
[09:07:44] <JohnResig> DaveMethvin: but that still breaks apps
[09:07:49] <DaveMethvin> do we  have a plan for non-regressive rAF?
[09:07:53] <JohnResig> it's just papering overing the solution
[09:07:55] <gnarf> JohnResig: considering the handling of timeouts / intervals in the spec - its going to break apps anyway
[09:08:09] <JohnResig> gnarf: then maybe rAF isn't for us!
[09:08:15] <DaveMethvin> i agree, but do we have a solution that can land in a month?
[09:08:20] <danheberden> didn't attr/prop have the same issue? wouldn't the better answer for them be to not upgrade yet?
[09:08:22] <gnarf> i'm talking about if we remove raf, we sitll have issues
[09:08:40] <rwaldron> gnarf, is FF cycling down set(Timeout|Interval) when out of focus now too?
[09:08:47] <paul_irish> yes
[09:08:48] <JohnResig> danheberden: it did, thus we reverted all the changes in 1.6.1
[09:08:52] <gnarf> rwaldron: yes
[09:08:57] <rwaldron> paul_irish was that yes to me?
[09:09:01] <danheberden> reverted or fixed
[09:09:02] <paul_irish> yes
[09:09:05] <rwaldron> ;)
[09:09:08] <rwaldron> cool
[09:09:19] <gnarf> so, even if we go to an rafless approach, there will still be animations that break
[09:09:26] <gnarf> for the same "reasons"
[09:09:27] <ajpiano> ^^
[09:09:41] <rwaldron> so, JohnResig see above, where part of the "regression"
[09:09:43] <rwaldron> hahah
[09:09:47] <rwaldron> we echo ditto
[09:09:50] <rwaldron> :D
[09:09:50] <danheberden> just seems weird we got to a good place of no new features in point releases, and here we are removing one
[09:09:56] <JohnResig> gnarf: if that's the case, then how come rAF is exposing whole new realms of breaking apps
[09:10:15] <rwaldron> the changes coincide
[09:10:19] <JohnResig> danheberden: this isn't a feature, it doesn't change any exposed API, it caused a regression
[09:10:25] <JohnResig> rwaldron: coincide with what?
[09:10:39] <ajpiano> JohnResig: because now the same issue will exist with any pure setTimeout call in FF, no rAF necessary
[09:10:44] <ajpiano> ( i assume )
[09:10:49] <gnarf> right
[09:10:54] <rwaldron> the inclusion of rAF and the changes to setTimeout/Interval happened around the same time
[09:10:56] <paul_irish> https://developer.mozilla.org/en/window.setTimeout#Minimum_delay_and_timeout_nesting   FF5 and Chrome 11 + have their timers clamped to 1000ms in inactive tabs
[09:10:58] <rwaldron> approx
[09:11:17] <JohnResig> ah, that's informative
[09:11:32] <DaveMethvin> so let's start with a "statement of support" issue ... does everyone agree that it makes sense for browsers to reduce the cpu/battery impact of invisible windows?
[09:11:34] <JohnResig> ok, so it's more an issue with two new browsers then
[09:11:44] <gnarf> paul_irish: granted, I think thats a dumb idea - and needs to be removed from the spec...
[09:11:48] <rwaldron> DaveMethvin absolutely
[09:11:59] <JohnResig> if we can't fix it by backing it out then it really doesn't matter, does it?
[09:12:02] <rwaldron> esp with low power devices
[09:12:02] <JohnResig> just leave it in
[09:12:05] <gnarf> I think that we should support people who want to use raf
[09:12:20] <ajpiano> JohnResig: and if we can't fix it with timeouts because they'll be broken in the exact same way
[09:12:21] <ajpiano> then...
[09:12:27] <DaveMethvin> so we're back to the flag? :)
[09:12:29] <ajpiano> we have to call in the unicorns
[09:12:31] <JohnResig> ajpiano: complain to the browser?
[09:12:31] <gnarf> I think the flag a) adds a way to determine if raf is in use, b) adds a way to disable it
[09:12:39] <JohnResig> and if backing it out doesn't fix it - then how does a flag "fix it"?
[09:12:52] <ajpiano> JohnResig: i don't know if i think it's unreasonable of the browser
[09:12:52] <rwaldron> JohnResig it doesnt
[09:12:53] <JohnResig> why would we want to disable it if it does the same thing as setTimeout
[09:12:57] <rwaldron> its more of a pacifier
[09:13:07] <JohnResig> rwaldron: a pacifier for what?
[09:13:16] <DaveMethvin> bad code
[09:13:26] <ajpiano> rwaldron: but won't our "fixes" not work
[09:13:30] <JohnResig> but if the bad code still performs badly with setInterval then what's the point
[09:13:33] <rwaldron> for those people who file reports that blame us/rAF/etc for their wn poorly designed code
[09:13:40] <DaveMethvin> the rAF animations won't stack up
[09:13:43] <JohnResig> no need to implement a flag if it'll have the same result either way
[09:13:46] <DaveMethvin> with the flag
[09:13:47] <rwaldron> we say "here, shut it off if you want"
[09:13:53] <rwaldron> but it wont matter
[09:14:00] <JohnResig> rwaldron: that's not a reason to implement a flag
[09:14:07] <danheberden> DaveMethvin can you clarify that a bit
[09:14:09] <gnarf> JohnResig: the code that will still break in FF will still break in FF with their upcoming changes, but their break isn't as bad as our current break
[09:14:10] <ajpiano> but if shutting it off isn't shutting it off, then the flag is pointless
[09:14:17] <rwaldron> because the #2 & #3 browser are changing the behaviour of the "old way"
[09:14:28] <JohnResig> gnarf: you're speaking too vaguely, what are you referring to?
[09:14:32] <JohnResig> ajpiano: precisely
[09:14:40] <rwaldron> JohnResig I'm not really taking a side either way
[09:14:42] <DaveMethvin> there are two browser features that impact animations: rAF and slowed timers
[09:14:48] <danheberden> it sounds like raf is still a problem, just a tiny bit worse than the browsers's created one
[09:14:59] <DaveMethvin> when the tab is out of focus, any animations from rAF are queued
[09:15:02] <rwaldron> personally, if you asked me to make the final decision... I'd say "no flag"
[09:15:08] <DaveMethvin> so when the tab comes back into focus they all run at once
[09:15:09] <JohnResig> well, is rAF worse than setTimeout, or not - you guys just said that they were identical
[09:15:10] * paul_irish wonders where he can read how apps break because of this stuff..
[09:15:13] <ajpiano> so then it's like a "this is a new best practise" situation where the question is one of education, not one where we just try to come up with really clever hacks with timeouts to
[09:15:13] <JohnResig> so either they're identical, or not
[09:15:20] <JohnResig> if rAF is worse, then it goes out, end of story
[09:15:22] <rwaldron> this is of course after long consideration of all povs
[09:15:28] <JohnResig> if they're identical, then it stays in and we add no flag
[09:15:51] <gnarf> JohnResig: So, if Intervals/Timeouts are clamped to 1000ms, the problem we have with rAF currently will still be visible in areas where the durations are within 1000ms
[09:15:57] <danheberden> DaveMethvin in that situation, what happens with setTimeout?
[09:16:13] <ajpiano> JohnResig: presumably the issue would end up being like, ok, you'd get these intensely stacked animations, but they'd be weirdly throttled at the rate of the min setTimeout interval
[09:16:31] <ajpiano> so "less broken" isn't really less broken looking, it's just slightly less seizure-inducing
[09:17:18] <JohnResig> ajpiano: by "stacked" in this case you mean the jQuery-style animation queue?
[09:17:23] <DaveMethvin> as for why something might break, imagine a slide show where a setInterval advances the slide every 10 secs, and an rAF animation is fired based on the setInterval
[09:17:30] <danheberden> so the clamped timeouts - the 1000ms, will happen in the background and raf will happen when the user gets back ot the page?
[09:17:38] <danheberden> or tab, ratherr
[09:17:48] <DaveMethvin> the js is gonna put a new animation in there every 10 secs regardless of whether the prev is done or not
[09:17:55] <ajpiano> JohnResig: i mean like, a bunch of animations all rapidly playing back to back, yep
[09:17:57] <DaveMethvin> and with rAF and an inactive tab it on't be done
[09:18:09] <gnarf> I can write a setTimeout that "lessens" the raf impact
[09:18:24] <rwaldron> eek
[09:18:25] <ajpiano> gnarf: what is the point of lessening it.
[09:18:30] <gnarf> but because of the deferring nature of the timeouts, it has issues
[09:18:33] <rwaldron> sounds fragile
[09:18:40] <gnarf> if it weren't for this clamping timeout shit, it would be great
[09:18:58] <danheberden> and dequeing when the tab regains focus?
[09:19:23] <rwaldron> danheberden i was just thinking...
[09:19:27] <danheberden> monitor the blur/focus times
[09:19:34] <rwaldron> "what if we ___ when blur/focus"
[09:19:36] <danheberden> and fulfill animations according
[09:19:37] <rwaldron> or something
[09:19:40] <danheberden> *accordingly
[09:19:44] <rwaldron> if !focus, don't do stuff
[09:19:47] <timmywil> hey all, trying to catch up in the logs
[09:19:51] * rwaldron shrugs
[09:19:55] <rwaldron> hey timmywil
[09:20:07] <DaveMethvin> the irony is that one really good reason for clamping sub-1sec timeouts is ... ANIMATIONS, which we are now "solving" with rAF!
[09:20:08] <JohnResig> what if we just don't queue animations when raf is waiting? or, perhaps better, only respect the last queued animation?
[09:20:25] <gnarf> if we are only dealing with "animation" on the queue, there is another way to handle it
[09:20:40] <ajpiano> JohnResig: i have my doubts about the latter being something desirable
[09:20:53] <danheberden> JohnResig I think with the understanding of what the browser is doing, the bad effects can be minimized
[09:20:55] <timmywil> how would we know when it's waiting
[09:21:08] <DaveMethvin> what timmywil said, is there a way to know?
[09:21:22] <danheberden> if you leave the page with a running queue?
[09:21:23] <JohnResig> or we could even just make all the queued animations synchronous, so that they all complete instantly when the user visits the page again
[09:21:41] <gnarf> there is a big if there tho JohnResig
[09:21:47] <gnarf> if there isn't a "delay"
[09:21:54] <gnarf> or some other non-animation queue func
[09:22:23] <gnarf> we can't just play the whole queue on return
[09:22:42] <timmywil> This is something that will take some time to figure out and while we are figuring it out, removing raf is the least messy option.
[09:22:59] <JohnResig> timmywil: agreed
[09:23:49] <ajpiano> which, we should realise, means that most people who are doing javascript animations in their app are going to not get rAF even though it's implemented in bowsers
[09:24:29] <JohnResig> yes
[09:24:33] <danheberden> which since we broadcasted that, sounds like a feature
[09:24:41] <JohnResig> this isn't the first time that we've not implemented a busted browser "feature"
[09:24:55] * danheberden is done with his argument of feature :)
[09:25:00] <DaveMethvin> i disagree with calling it "busted" though
[09:25:08] <JohnResig> (busted in that it doesn't work well for us without considerable work)
[09:25:11] <gnarf> the "feature" isn't broken, the code organization of some peoples animation code is "busted"
[09:25:23] <DaveMethvin> it's a very good idea but there is code that makes assumptions that break it
[09:25:36] <ajpiano> JohnResig: pretty sure we had more outcry about ?7535 than this
[09:25:46] <ajpiano> ?7535
[09:25:47] <bot-t> [#7535] Firefox Console error: Unexpected token in attribute selector: '!' (closed bug: wontfix) - http://jqbug.com/7535
[09:25:56] <DaveMethvin> yeah, if you advance a slide every 10 secs and the user isn't there to see it, you shouldn't be advancing the slide
[09:26:05] <paul_irish> is this usecase for how this breaks what DaveMethvin mentioned above? just a repetitive timer that kicks off a rAF animation ?
[09:26:22] <rwaldron> ajpiano yooouuuu sunnovabitch
[09:26:31] <DaveMethvin> paul_irish: yes that's the most common one
[09:26:31] <ajpiano> rwaldron: i'm just saying,
[09:26:34] <gnarf> paul_irish: anything that queues animations without thinking about it while the page isn't visible --- the most common being the reptitive timer
[09:26:41] <DaveMethvin> fixable by having the animation complete fn advance the slide for example
[09:26:45] <rwaldron> ajpiano i just had a PTSD flashback from that
[09:26:48] <rwaldron> so, thx
[09:27:42] <ajpiano> i just am not sure if "10 people complained, so no one ever gets rAF is a good idea"
[09:27:44] <DaveMethvin> so anyway i think it's more fair to say some people's assumptions are busted to the point that rAF can't be used effectively
[09:27:44] <timmywil> or a clock that has to animate every second
[09:27:46] <gnarf> Will removing rAF break less peoples code? Yes - Do I think we should be encouraging this bad animation code design? No
[09:28:01] <DaveMethvin> what gnarf said
[09:28:06] <ajpiano> esepially when the issue can be workd around in end-user code,
[09:28:11] <paul_irish> ya
[09:28:17] <DaveMethvin> but the q is whether there is enough broken code to justify backing it out
[09:28:36] <DaveMethvin> esp when the slow timer thing still is there
[09:29:09] <DaveMethvin> i'm not rabid one side or the other, i'm just sitting here rocking with my head in my hands over what a mess this is
[09:30:04] <DaveMethvin> in our earlier discussions it seemd like this has GOT to end with developers understanding the changes and writing their code differently
[09:30:19] <ajpiano> i don't think anyone is particularly rabid actually, just trying to figure out what the right answer really is :/
[09:30:38] <gnarf> Yeah, I'm just speaking up for rAF cuz I don't want it to go away without a fight.
[09:30:50] <gnarf> I think it's an enhancement we know we want, and we want people to use
[09:30:56] <gnarf> so I think removing it is a bad idea
[09:30:57] <DaveMethvin> ajpiano: take advantage of all browser features without breaking any old code, natch
[09:31:16] <ajpiano> i just don't even think like, that many people have complained relatively speaking
[09:31:24] <ajpiano> given the *potential* for how many people do this type of thing
[09:31:38] <ajpiano> have they just not upgraded? or did they work around it?
[09:31:55] <DaveMethvin> well there are a few common plugins that fall prey to this, i guess that's good b/c it's easy to fix a few plugins
[09:32:09] <gnarf> Most people use animation callbacks
[09:32:15] <gnarf> which doesn't break
[09:32:19] <DaveMethvin> remember that the majority of jquery sites are still on old versions that don't support rAF
[09:33:22] <gnarf> And like I stated in the forum post, either way, I'm going to be talking about this issue in detail in my talk @ jqcon :)
[09:33:59] <timmywil> There is another way to look at the slow timer issue.  There may not be much more CPU load optimization provided with raf over a regular timer and at that point, the biggest advantage is the improved efficiency in block execution + redrawing. If that's not an issue (meaning there is no noticeable improvement in FF/Chrome), it doesn't give us much of a reason to include raf in the first place.
[09:34:55] <gnarf> timmywil: other than stopping that jQuery slideshow in the hidden tab on my android from sucking up all my CPU
[09:35:29] <DaveMethvin> timmywil: i see your point, though, the timer is only firing once a sec so the cpu/battery impact is a lot less already
[09:35:55] <DaveMethvin> that makes the battery benefit of rAF a lot less attractive
[09:36:01] <timmywil> DaveMethvin: exactly
[09:36:01] <gnarf> ahh
[09:36:04] <gnarf> missed the intro point
[09:36:05] <gnarf> sry
[09:36:08] <gnarf> ++
[09:36:32] <DaveMethvin> i think that is a winning perspective
[09:36:44] <DaveMethvin> one we can use in the blog post :)
[09:37:06] <DaveMethvin> "why we backed out rAF"
[09:37:42] <gnarf> I'm not sure that mobile webkit does this timer slowage
[09:38:25] <DaveMethvin> for the future, there's always the page visibilty api
[09:38:33] <timmywil> JohnResig: what you thinkin
[09:38:38] <paul_irish> its a fairly recent change to webkit so it hasnt made its way around yet, gnarf
[09:38:51] <paul_irish> probably the newest nokia n90 or w/e has it
[09:38:59] <gnarf> paul_irish: I really think that change needs to be questioned a LOT
[09:39:18] <JohnResig> timmywil: I'm agreeing with you and DaveMethvin here
[09:39:20] <gnarf> paul_irish: but thats for someone elses meeting ;)
[09:39:40] <DaveMethvin> gnarf: lol
[09:39:44] <paul_irish> gnarf: there hasnt been much dissent about it on the standards lists fwiw
[09:39:55] <gnarf> paul_irish: They can just look at our experience for why its a horrible idea :)
[09:40:10] <DaveMethvin> the standards guys don't make web sites, just standards
[09:40:24] <paul_irish> they also have no idea about your POV unless you tell them :)
[09:40:28] <JohnResig> I mean, querySelectorAll came out so perfectly /snark
[09:40:43] <DaveMethvin> lol
[09:41:37] <gnarf> I guess I'll just never use jQuery 1.6.3
[09:41:39] <rwaldron> JohnResig ahaha
[09:41:41] <gnarf> :)
[09:41:50] <rwaldron> querySelectorBlackHole()
[09:41:51] <timmywil> ha
[09:41:54] <DaveMethvin> gnarf: file a bug report
[09:42:34] <DaveMethvin> so ok, 45 minutes later we're ok with qSA being removed from 1.6.3 then?
[09:42:36] <rwaldron> gnarf why not offer a duckpunched jQuery.fn.animate ?
[09:42:37] <gnarf> I think the benifits to including rAF are still valid, and that removing it doesn't really solve the problem, it just hides it
[09:42:45] <gnarf> rwaldron: because its not .animate
[09:42:46] <timmywil> DaveMethvin: hahaha
[09:42:48] <gnarf> its the timer
[09:42:58] <gnarf> and its not abstracted well enough to duck punch it
[09:43:11] <rwaldron> i guess you're right
[09:43:17] <DaveMethvin> that's why the flag sounded good, if rAF was worth keeping
[09:43:17] <ajpiano> requackstAnimationFrame
[09:43:17] <ajpiano> :/
[09:43:23] <rwaldron> i was just trying to throw a posi spin out there
[09:43:42] <rwaldron> ajpiano++
[09:43:46] <DaveMethvin> even if the flag had it turned off by default
[09:44:03] <gnarf> DaveMethvin: I still think the "flag" needs to be seen more as a "support test"
[09:44:30] <DaveMethvin> gnarf: that definitely makes it easy to implement ... and remove!
[09:44:31] <louisremi> This is a lot of debate for an issue we cannot solve ;-)
[09:44:37] <timmywil> I think we're going in circles now
[09:44:48] <DaveMethvin> louisremi: right, now on to the budget deficit
[09:44:58] <louisremi> DaveMethvin: :D
[09:44:59] <DaveMethvin> we have 15 minutes
[09:45:03] <gnarf> I'm done arguing, I put all my points out there... Twice ;)
[09:45:08] <timmywil> shall we vote?
[09:45:10] <ajpiano> gnarf: new 1.7 or 1.8 feature... expose jquery animation timers :p
[09:45:23] <DaveMethvin> yeah this isn't getting back in for 1.7 i think, too much to digest in a month
[09:45:26] <gnarf> ajpiano: gonna have to be 1.8 before we reinclude raf / timers changes
[09:45:28] <DaveMethvin> so keep that in mind
[09:45:49] <timmywil> animate is scheduled for a rewrite in 1.8 so that might be a perfect time for it
[09:45:56] <louisremi> ajpiano: that won't help anyone. They have to rework their animation logic to take account of the pauses when tabs are inactives. That's it.
[09:46:18] <gnarf> I guess my point is, either people fix their code now
[09:46:18] <DaveMethvin> louisremi: and the page visibility api may help there
[09:46:31] <gnarf> or it breaks later anyway
[09:46:35] <gnarf> no fault of jQuery
[09:46:43] <louisremi> gnarf: true
[09:47:01] <gnarf> so why not expose the vulnerability in the poor logic the end user has now
[09:47:31] <louisremi> DaveMethvin: the page visibility API might help, but I've been able to fix slideshows by just using .stop() to prevent animation stack to build up
[09:47:54] <ajpiano> gnarf: cause apocalypse is coming in 2012, this way people can enjoy the rest of their lives in peace
[09:47:54] <ajpiano> :/
[09:48:20] <DaveMethvin> okay, by removing rAF support we're saying that 1.6.3 and 1.7 won't support it, and 1.8 timeframe (January) we'll have some solution
[09:48:30] <DaveMethvin> damn that sounds scary when i write it that way
[09:48:30] <louisremi> wut?
[09:48:58] <louisremi> When in this conversation did you guys agreed to remove raf? Did I miss something?
[09:49:05] <gnarf> If its coming to a vote, I vote against removal
[09:49:07] <DaveMethvin> it's gone already
[09:49:15] <gnarf> not that my vote counts for anything :)
[09:49:19] <ajpiano> louisremi: last week :p
[09:49:20] <timmywil> gnarf: sure it does
[09:49:20] <DaveMethvin> gnarf: untrue!
[09:49:36] <DaveMethvin> nobody came to last weeks meeting so it was short :P
[09:49:56] <louisremi> oh god, why did I miss so many meetings... And, did removing it fixed ANYTHING?
[09:50:06] <JohnResig> dear god, again?
[09:50:18] <timmywil> louisremi: there's a forum thread
[09:50:33] <timmywil> also, meeting logs.  it's a lot to go through again
[09:50:37] <ajpiano> can we uh, move on for now
[09:50:41] <louisremi> okay, I'll have a look and stop bothering you, sorry
[09:50:55] <DaveMethvin> so, 1.6.3 release ... happening this week?
[09:50:59] <DaveMethvin> the reason i ask is that we can'
[09:51:05] <JohnResig> are we squared away?
[09:51:19] <DaveMethvin> the stuff i linked needs to be fixed or closed
[09:51:26] <DaveMethvin> still some stuff to do
[09:51:44] <DaveMethvin> i kinda hoped we'd  have time to talk about it
[09:52:12] <JohnResig> guess we could push to next week and discuss later?
[09:52:15] <JohnResig> fix the bugs this week?
[09:52:31] <DaveMethvin> yeah, it does push 1.7 as well
[09:52:36] <JohnResig> oh, hmm
[09:52:39] <JohnResig> we don't want that
[09:52:48] <DaveMethvin> if we're gonna land 1.7 fixes in trunk
[09:53:04] <DaveMethvin> goood idea to leave a week or so after 1.6.3 for critical changes
[09:53:11] <gnarf> so re 1.6.3
[09:53:15] <DaveMethvin> i mean we can do it but it just gets messier
[09:54:08] <gnarf> http://bugs.jquery.com/ticket/6150#comment:10 -- Anyone have any comments on providing a "stop" hook or should I just make it a non-property animation?
[09:54:31] <DaveMethvin> how about 1.6.3 on Monday 29 then/ gives us a week
[09:55:45] <timmywil> +1
[09:56:06] <DaveMethvin> how about if we come up with the deadlines here and then move the tech discussions back to -dev, will that work?
[09:56:12] <gnarf> sure
[09:56:31] <timmywil> what was the tentative date for 1.7?
[09:56:34] <gnarf> I have no opinion on the deadlines, so if anyone has an opinion about that ticket, PM / -dev me ;)
[09:56:55] <DaveMethvin> beta for the jqconf?
[09:57:06] <DaveMethvin> prolly don't want to release and then be at the conf
[09:57:07] <JohnResig> oof, I would like to do final for jqconf
[09:57:23] <JohnResig> but if it's getting too rough, then yeah, we can do beta
[09:58:16] <DaveMethvin> so when should everyone have their stuff in for beta? i'd like to shoot for mid-Sept so we have a decent beta period and can do fixes
[09:58:40] <timmywil> Sept 12?
[09:58:56] <DaveMethvin> worksforme
[09:59:48] <JohnResig> yeah, I'm fine with that
[10:00:52] <DaveMethvin> if we don't have too many problems we could get a release for the conf
[10:00:57] <timmywil> If that works out, we could possibly do 2 weeks for beta, rc on the 26th and release at jqcon
[10:01:18] <JohnResig> I've got a meeting I've gotta run to, sorry!
[10:01:21] <DaveMethvin> np
[10:01:35] <DaveMethvin> i think we got the dates done, that was my goal
[10:01:43] <DaveMethvin> cya back at -dev!
[10:01:52] <timmywil> kk