18:02:14 <mikeperry> #startmeeting tbb-dev
18:02:14 <MeetBot> Meeting started Mon May  4 18:02:14 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:14 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:03:43 <mikeperry> ok, let's get started
18:03:58 <mikeperry> Last week, I posed the release, and kept an eye on the blog comments. We now have a new trac for new issues introduced in the 4.5 release: https://trac.torproject.org/projeicts/tor/query?keywords=~tbb-4.5-regression&status=!closed I don't think any of them are severe enough to block updating 4.0 users, though.
18:04:13 <mikeperry> I also posted updates to the design doc for 4.5, but some more remean. See #15580. I also sent in a position paper for Tor for HTTP/3.
18:04:19 <mikeperry> s/remean/remain
18:05:19 <mikeperry> This week, I need to update our trac tags for the next month, write the TBB status report, finish the design doc updates, and post the update notifications for 4.0 users. I'm also planning on doing some roadmapping, and looking at the firefox design docs.
18:06:00 <mikeperry> I need to decide where to put the position paper(s). I think tor-browser-spec.git seems an OK place... that's where the branch lives now, anyway
18:06:07 <GeKo> I wonder whether we should push the update notification at all given that we have a new release coming next week
18:06:44 <GeKo> we could fix the important regressions and just use the update notifications 4.0.8 -> 4.5.1
18:07:08 <mcs> I think it makes sense to skip the 4.5 update and just go to 4.5.1 (for 4.0.8 users)
18:09:42 <mikeperry> hrmm
18:10:08 <mcs> Or maybe that is too long to wait?
18:10:36 <mcs> Overall, TB 4.5 seems to be well received.
18:11:48 <mikeperry> it was my feeling that the regressions weren't serious.. pushing the update earlier may also give mac 10.6 and 1.7 users time to figure out what they need to do to get on 4.5
18:13:16 <GeKo> I am fine with that. It might just be annoying for users to update twice within a week and won't us save anything as we will have to build incrementals for 4.0.8 -> 4.5.1 anyway, I think
18:13:28 <GeKo> *sve use
18:13:43 <GeKo> *sigh*: *save us
18:14:17 <mcs> #15872 is kind of bad, maybe.  I am not sure if all Windows users cannot use meek or ?
18:14:43 <isis> "the meek"
18:15:19 <GeKo> yes and the clearclick thing is pretty confusing as well I guess
18:15:24 <mcs> and maybe #15899
18:15:25 <GeKo> (#14985)
18:17:11 <GeKo> anyway, here are some highlights from me:
18:17:49 <GeKo> I helped with the release and the fallout
18:18:19 <GeKo> I worked on #15578, #14985, #15580, #15581
18:20:01 <GeKo> I wrote a small patch for #15773, investigated #15909
18:20:35 <mikeperry> do you think we'll have a fix for #14985 this week?
18:21:00 <GeKo> this week I plan to finish the Tor Browser design doc work do a bunch of reviews for the release next week, try to figure our #14985 and if time permits I start working on gitian things
18:21:26 <GeKo> transitioning away from lucid and getting esr 38 to compile in our environment
18:21:35 <GeKo> that's it for me
18:24:48 * arthuredelstein can go
18:24:53 <arthuredelstein> Last week I wrote patches for #15897 and #15899.
18:25:03 <arthuredelstein> And I rebased a few patches for #15196.
18:25:32 <arthuredelstein> And I kept working on bugzilla.mozilla.org/show_bug.cgi?id=418986 which unfortunately has a couple of mysterious test failures on B2G that I still need to fix.
18:25:57 <arthuredelstein> So this week I hope to fix those failures, and work more on the ESR 38 rebasing.
18:26:29 <GeKo> is everything you have for #14429 pushed?
18:26:50 <GeKo> I think we should test the new code in 5.0a1 but I'd like to review it first
18:26:50 <arthuredelstein> Yes, I think so. I can rebase it to torbutton master again if that would help.
18:26:57 <GeKo> thta would be nice
18:27:00 <GeKo> *that
18:27:11 <GeKo> have you tested with a tiling wm?
18:27:29 <arthuredelstein> Sounds good. Yes, at least 5.
18:27:40 <GeKo> ha, okay :)
18:27:55 <arthuredelstein> Basically it turns off resizing for tiling wms
18:28:14 <GeKo> ah
18:28:15 <arthuredelstein> And instead just zooms to fill the tile with content
18:28:59 <arthuredelstein> I would say the biggest remaining problem I am aware of is that zooming is sometimes a little larger than is comfortable.
18:29:13 <arthuredelstein> Especially for small screens
18:29:40 <arthuredelstein> But I haven't come up with any clever ideas to avoid that problem.
18:29:59 <arthuredelstein> (zooming happens when a window is maximized, or in a tiling wm tile)
18:31:29 <arthuredelstein> Anyhow, that's all for me.
18:32:57 * mcs can go next
18:33:10 <mcs> Last week, Kathy and I spent some time reviewing the changes that Mozilla has made to the Firefox updater code since ESR31.
18:33:18 <mcs> The good news is that although many changes have been made, most of them are not architectural in nature.
18:33:27 <mcs> There will be a lot of conflicts to work through.  We actually started rebasing patches to Mozilla's release branch (where the Firefox 38.0 work is being done) and have made a little progress.
18:33:35 <mcs> We have also kept an eye on TB 4.5 release feedback and tried to be responsive to bug reports, etc.
18:33:41 <mcs> Lastly, we did some bug triage (e.g., #15800 and #15857) plus our end of month report, etc.
18:33:49 <mcs> This week, we will help with TB 4.5 fallout,
18:33:54 <mcs> continue with the ESR38 updater rebase work,
18:33:59 <mcs> and help with whatever else comes up.
18:34:07 <mcs> That's all for us.
18:35:44 * boklm can go next
18:35:47 <mikeperry> ok. make sure you coordinate with arthuredelstein with patches. he was going to do some of that as well
18:36:34 <boklm> Last week I fixed some problems in the script to convert tor-browser.git to a mercurial queue to push to Mozilla Try ( https://github.com/boklm/tor-browser-try )
18:36:35 <mcs> Yes, we have been in contact.
18:36:44 <boklm> (now squashing all tor-browser commit into a single mercurial changeset, because git format-patch does not work with merge commits fixing conflicts, as we have now in tor-browser.git)
18:36:51 <boklm> I pushed tor-browser-31.6.0esr-4.5-1 to mozilla try, and fixed some build problems: #15921 and #15922
18:37:03 <boklm> This week I'm planning to fix the other build problems we have on mozilla try
18:37:06 <boklm> I'm also planning to look at how much build time it would add if we were running our unit tests (only the ones we add with our patches, not all mozilla tests) as part of our build process, to see if that's something we could do
18:37:27 <boklm> that's all for me
18:38:52 <mikeperry> I just had a coffee disaster :/
18:39:37 <GeKo> no coffee?
18:39:43 <GeKo> too much?
18:39:49 <mikeperry> worse, spilled coffee
18:39:54 <GeKo> ugh
18:40:59 <mikeperry> boklm: that sounds good re unit tests.
18:41:28 <mikeperry> I pushed the HTTP/3 position paper (and the older W3C position papers too).
18:41:31 <mikeperry> https://gitweb.torproject.org/tor-browser-spec.git/plain/position-papers/HTTP3/HTTP3.pdf
18:41:50 <mikeperry> GeKo: not sure if you saw the submitted version of that
18:42:33 <GeKo> I downloaded it from that easychair thing but have not had time to look at it yet
18:43:10 <GeKo> (I hope my stuff was at least a bit useful :) )
18:43:13 <mikeperry> ok, yeah I wasn't sure if you would be able to do that. well, it's up anyway
18:43:50 <mikeperry> yeah, it was a start
18:44:33 <mikeperry> it became difficult to keep it focused on what is important and still somewhat brief, after a while
18:45:30 <GeKo> indeed, I fought with that too
18:46:28 <mikeperry> anyway, with respect to the release, one of my side concerns is that Disconnect wants an early meaure of how many users we're going to have long term, because right now they are paying for extra capacity they are not yet sure they will need. so that would be one reason to release 4.5 to the 4.0 users erlier
18:46:45 <mikeperry> but OTOH, it is just 1 more week, and avoiding annoying our stable users seems worthwhile
18:47:47 <mikeperry> I had originally thought the next point release was the 19th somehow.. I think my brain mixed up the tagging and release dates in the chaos of the 4.5 release
18:48:48 <mcs> Mozilla moved the release back one week at some point.
18:48:56 <GeKo> yes
18:48:56 <mcs> So you are not insane.
18:50:02 <mikeperry> let's not rule anything out prematurely ;)
18:50:15 <GeKo> haha
18:52:25 <mikeperry> ok, let's hold off on updating the 4.0 users, then. I think the meek bug is worth waiting for
18:53:10 <mikeperry> updating windows 7 users and breaking their the meek isn't very nice. it may be hard for them to get another copy
18:53:53 <GeKo> yes
18:57:23 <mikeperry> ok. I think the ICU MacOS bug is a bit scary. the rest we can take. we will also have tags tomorrow most likely for the new 38esr, as well as the new point release for 31esr
18:58:52 <mikeperry> I guess we try to have build tags on thurs/fri again
18:59:35 <mikeperry> so any regressions we can get in by then will be good.
18:59:53 <GeKo> I think we should have an esr38 branch in our tor-browser repo then as well, right?
19:00:41 <mikeperry> possibly. mostill may or may not actually call ff38 esr38 in their repo for a bit. we'll see, I guess
19:02:02 <mikeperry> s/mostill/mozilla
19:02:16 <mikeperry> anything else for the meeting today, then?
19:04:24 <mikeperry> ok, that's a wrap then. thanks everyone. keep an eye on those regression tags/bugs for review, fixes, etc!
19:04:35 <mikeperry> #endmeeting *baf*