18:02:22 <mikeperry> #startmeeting tbb-dev
18:02:22 <MeetBot> Meeting started Mon Mar 30 18:02:22 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:22 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:02:49 <msvb-out> arthuredelstein: Or Karsten? Not sure.
18:03:14 <Sebastian> arthuredelstein: did you los the content or do you still have it?
18:03:29 <arthuredelstein> I still have it. I just keep getting rejected.
18:03:42 <kernelcorn> this meeting is on the Tor Browser, yes?
18:04:15 * isabela would like to give an update at discussion time
18:04:22 <mikeperry> yes, let's get started
18:04:27 <mikeperry> isabela: ok sounds good
18:04:52 <mikeperry> Last week, I cleaned up #13375 based on GK's testing and review, closed #13766 and then went with #15482 instead, and went on a bit of a merge rampage trying to get things in for 4.5a5 (in the process merged some things I shouldn't have in the rush - thanks for everyone who was paying close attention and caught mistakes). I then wrote the changelog for 4.5a5 and then GK and I went through an agonizingly
18:04:59 <mikeperry> long series of builds (5 or 6 depending on how you count) trying to get everything right.
18:05:16 <mikeperry> However, all-in-all I'm very happy with TBB 4.5a5, and everyone derserves thanks and congratulations for their hard work and dedication to getting everything ready in time. I really do think that TBB 4.5 will be the most user-friendly release we've ever made, and I look forward to seeing our download and update ping counts rise over the coming point releases.
18:05:16 <arthuredelstein> Sebastian: Probably it's best if we discuss after the Tor Browser meeting.
18:05:34 <Sebastian> arthuredelstein: #tor-project
18:05:40 <mikeperry> This week I plan to finish up the TBB releases for Tuesday, write the monthly status report, and go through the TBB-4.5 and monthly tickets to determine our plan for 4.5-stable and the rest of the month.
18:06:03 <mikeperry> GeKo and I have some final coordination to do to decide who takes what part of the releases for Tuesday
18:06:07 <mikeperry> but that's it for me for now
18:08:26 * mikeperry wonders if he was too last-minute in the adjustment of the meeting time for EU Summer Time. Is anyone else around? ;)
18:08:40 <GeKo> huh, meeting
18:08:43 * boklm is around
18:08:44 <isabela> hehe
18:08:52 <GeKo> i am, now
18:09:07 * mcs is here.
18:09:26 <mikeperry> yay!
18:09:39 * mcs can go next
18:09:48 <mcs> This past week, Kathy and I fixed #15406 and also prepared a fix for #13576 (needs to be reviewed).
18:09:57 <mcs> We did some miscellaneous bug triage, e.g., for #12682, #15473, and #15502.
18:10:11 <mcs> We reviewed GeKo's fix for #7255.
18:10:20 <mcs> And we did some testing of the TB 4.0.6 and 4.5a5 release candidates.
18:10:27 <mcs> This week we will work on #15491 and help with other remaining 4.5 issues.
18:10:33 <mcs> Also, Kathy and I will both be away from the office late this week and the first part of next week.
18:10:41 <mcs> That's all for us.
18:13:11 <mikeperry> mcs: ok, great. I am actually planning to send everyone an email telling them that we should all try to take a breather and a few days off after 4.5a5. it was a bit intense (esp with pwn2own and the late Mozilla tagging)
18:15:34 * boklm can go next
18:15:43 <mcs> mikeperry: I appreciate you looking out for everyone. Don't forget to take a breather yourself.
18:16:02 <boklm> This past week I have been mainly working on tor-messenger stuff
18:16:04 <boklm> Other than that I updated the security sliders tests for the latest torbutton changes (the testsuite with those changes is running on 4.5a5 at the moment)
18:16:10 <boklm> And started looking at the test page for #15511
18:16:23 <boklm> This week I'm planning to add tests for #15511 and #13375, and look at having some nightly builds
18:16:44 <boklm> that's it for me
18:17:01 <GeKo> boklm: what happened to the virus total thingy?
18:17:16 <boklm> GeKo: hmm, I need to check
18:18:12 <GeKo> hre is what I did: apart from the release related things I worked on:
18:18:16 <GeKo> *here
18:19:28 <GeKo> #7255, #15460, #6503 and #15510
18:19:49 <GeKo> I spent quite some amount of my time with testing #14429, #13755 and #13019
18:20:09 <GeKo> and I thought a bit about #4100 and #15502
18:21:15 <GeKo> this week I plan to work on getting the release out, update related documentation (#15252 is in the review queue)
18:21:43 <GeKo> and give the alpha more testing (this already uncovered #15510)
18:22:14 <GeKo> I planned to look at our roadmap to map the bugs to a sponsor
18:22:20 <GeKo> not sure if I get to that
18:22:26 <GeKo> that's it for now
18:23:34 * arthuredelstein can go
18:23:38 <arthuredelstein> This past week I worked on patches for #13019, #15460, #15472, and #14429. I also did code review for #13766. And I made some revisions and exegesis for my patches in #13670. This week I'll work on further improvements for #14429 and #15474 and maybe #15239.
18:24:11 <arthuredelstein> that's it for me
18:27:08 <mikeperry> so a while ago we disabled site-specific zoom
18:27:25 <mikeperry> however it appears that it still remembers zoom for the current tab when you change sites
18:28:59 <mikeperry> one option that might be simpler for #15474 is just make sure that zoom is reset upon navigation to a new site. Not ideal for people who rely on zoom to read, but it may make it less of a linkability risk and may be a simpler change if #15474 proves to have lots of OS-dependent edge cases like #14429 did
18:29:35 <arthuredelstein> That's a good point.
18:30:10 <arthuredelstein> One tricky issue is that if we adjust dimensions to handle zooming on one tab, then the dimensions are wrong on another unzoomed tab.
18:30:13 <mikeperry> I have also noticed the same edge cases with #14429 that GK has, btw. the alt key is an especially irritating one :/
18:30:21 <mikeperry> arthuredelstein: ah, yes
18:30:55 <arthuredelstein> Yes, I'll be looking into the alt key soon
18:31:44 <arthuredelstein> One possibility would be to have a global zoom setting only. All tabs and windows zoom in and out together.
18:32:29 <GeKo> I wonder if we would get further by trying the C++ patch road for #14429. I fear we end up in the same mess as we did when implementing the resizing on start-up feature.
18:32:38 <mikeperry> sounds like an option, but I wonder if that will make #13875-type things worse
18:33:31 <mikeperry> (the global zoom idea)
18:33:33 <arthuredelstein> GeKo: Yes, I think it's worth considering that for addressing at least some parts of the problem.
18:34:35 <arthuredelstein> mikeperry: Definitely something to check.
18:35:32 <GeKo> the global zoom option sounds like a good idea to me
18:37:23 <mikeperry> GeKo: your #4100 experiment is very interesting. I wonder if that is a side effect of arthur's nsIChannelProxyFilter implementation. prior to our use of that, the HTTP stack would see that an already-available HTTP keep-alive connection was open, and send the request down it. since the connection was already open, no SOCKS handshake was involved
18:37:36 <mikeperry> but perhaps there is logic that causes it not to do that if the proxyInfo has changed
18:38:04 <mikeperry> which would be great news for SPDY and for HTTP/2, if it is the same there
18:38:10 <GeKo> yes, I thought so, too
18:38:39 <GeKo> I actually thinkg this is due the nsIChannelProxyFilter
18:38:56 <GeKo> I have not had time to look at it closer though
18:39:10 <GeKo> *think
18:39:29 <GeKo> ugh, s/due/due to/
18:39:34 <mikeperry> the ability to raise the kee-alive would be a huge help for etherpad-type sites, and for google docs/gmail/webmail in general
18:40:38 <mikeperry> I am frequently disconnected from riseup/etherpads while editing them, and I suspect that some combo of our low keep-alive and the pre-#15482 behavior was to blame
18:41:18 <GeKo> we might want to look at it then for 4.5 might be some low-hanging fruit
18:42:17 <GeKo> and would fit pretty well to the usability boost this release comes with
18:42:47 <mikeperry> yep, already updated the tags on the bug :)
18:44:37 <mikeperry> ok, so I think either isabela should go, or we should discuss wrapping up+signing+posting 4.5a5
18:44:41 <mikeperry> maybe isabela first?
18:45:15 <isabela> sure
18:45:55 <isabela> is just a quick note about roadmaps - I am working with all teams trying to keep the roadmaps updated and reflecting the team's work.
18:46:18 <isabela> I wanted to ask the TBB team to review what you added for april and to let me know if there is any blocker or dependencies
18:46:42 <isabela> thats it - does any one has questions or comments?
18:47:12 <mikeperry> (our roadmap is at https://trac.torproject.org/projects/tor/wiki/org/roadmaps/TorBrowser for people who were just looking for it now)
18:47:27 <isabela> tx mikeperry
18:47:59 <mikeperry> the upstream deliverables for TBB are summarized here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorU/TorBrowser
18:48:13 <mikeperry> but those are over 2 years
18:48:20 <luketheduke> [A
18:49:42 <arthuredelstein> What's the schedule for the forthcoming 4.5 releases? Will 4.5 have a beta period?
18:50:00 <GeKo> no it will be stable in 2-3 weeks
18:50:36 <GeKo> we don't need beta periods ;)
18:50:40 <arthuredelstein> OK. And once it's stable, that means all new patches apart from bugfixes go into a 5.0-alpha branch, correct?
18:50:48 <mikeperry> we need to decide how we want to handle update channels. ideally, we'll keep the alpha users on an alpha channel somehow and also update 4.0 users to 4.5 as a stable channel update
18:51:09 <mikeperry> I am not sure if we want to auto-update 4.0 users to 4.5 for this first release in 2-3 weeks though. I think not?
18:51:15 <GeKo> arthuredelstein: yes, that's usually the case
18:51:28 <GeKo> unless there are things effecting stable as well pretty badly
18:51:31 <mikeperry> so that would make it more of a "soft" launch
18:52:08 <arthuredelstein> For the 5.0-alpha, we'll need to have rebased to ESR38, right?
18:52:24 <mcs> If we do not auto update people to 4.5 some will wonder why not… but a soft launch might be safer.
18:52:25 <arthuredelstein> I'l need to start working on that very soon then!
18:53:08 <GeKo> arthuredelstein: good question.
18:53:48 <GeKo> I think, no.
18:54:00 <intrigeri> (fwiw, we will probably ship 4.5-stable in Tails 1.4, scheduled for 2015-05-12)
18:54:20 <GeKo> but the switch is happening in the 5.0 alpha series hopefully
18:54:21 <mikeperry> I don't see a reason why the very first 5.0-alpha needs to be rebased on FF38esr
18:54:35 <arthuredelstein> Ah, OK. That makes sense.
18:54:40 <mikeperry> we should be careful about diverging torbutton and tor launcher strings for as long as we can
18:54:49 <mikeperry> so we can keep taking translation updates in 4.5
18:55:18 <GeKo> mikeperry: what do you mean with "soft launch"?
18:55:55 <GeKo> I thought we build a 4.5 say in 2-3 weeks and then update people coming from 4.0 to it.
18:56:47 <mikeperry> the "soft" part is if we auto-update the 4.0 people right away or not
18:57:06 <mikeperry> since it won't be timed with a Firefox security release (we hope), we won't absolutely need to update people
18:57:50 <mikeperry> which will give us some time to see if there are serious problems for some segment of the userbase with 4.5
18:57:54 <GeKo> ah, okay.
18:58:30 <GeKo> then I am in the "soft launch" camp, too, I think
18:58:49 <arthuredelstein> Since there are some bugfixes that will need to happen before the 4.5 stable release, I wonder if it would make sense to have an extra 4.5-alpha release in ~2 weeks. Not sure how difficult that is, though.
18:59:22 <mcs> With respect to the updater, we should be able to update alpha channel users to 4.5 stable but have them remain on the alpha channel. But we talked about this before and maybe there is some reason that won't work correctly?
19:00:03 <mcs> (that's a rhetorical question; Kathy and I can do some testing)
19:00:18 <mcs> (but I think that is what Mozilla does with Firefox)
19:00:26 <GeKo> I think we did the same thing with 4.0, did not we?
19:00:29 <mcs> (for the beta channel)
19:00:38 <mcs> Did it work ;) ?
19:00:38 <GeKo> and it worked IIRC
19:00:51 <mcs> OK. I think it did.
19:01:09 <mikeperry> ok, yes, I vaguely remember talking about this before and you saying it would work out. that sounds good
19:01:51 <GeKo> arthuredelstein: another alpha, no, I don't think so.
19:02:32 <mcs> Fixes will need to be carefully reviewed and tested as much as possible by us, I think.
19:02:40 <Yawning> armadev: So uh
19:02:42 <Yawning> that bug
19:02:51 <Yawning> def is reproducable
19:03:25 <Yawning> Mar 30 19:02:28.000 [err] tor_assertion_failed_(): Bug: ../src/or/onion_tap.c:58
19:03:27 <Yawning> : onion_skin_TAP_create: Assertion pkbytes == 128 failed; aborting. (on Tor 0.2.
19:03:29 <Yawning> 7.0-alpha-dev d2023c8979192654)
19:03:36 <arthuredelstein> GeKo: mcs: OK!
19:03:36 <Yawning> sigh
19:03:50 <mikeperry> we can also decide to auto-update 4.0 users at any point after the 4.5 release. that canjust be a function of if/when we publish the new update manifests
19:04:03 <GeKo> yes, sounds good
19:05:10 <GeKo> I wonder about the load we put with this strategy on our infrastructure, though
19:05:31 <GeKo> are we assuming that a great deal of users is still staying on 4.0?
19:05:51 <GeKo> does it matter?
19:06:34 <mikeperry> we should ensure we have incrementals for a couple of releases, I think? like we did with 4.0.6 (we made incrementals for 4.0.4->4.0.6 and 4.0.5->4.0.6)
19:06:57 <dgoulet> Yawning: yeah I made it explode also here in a chutney :S ...
19:07:29 <Yawning> :(
19:07:46 <Yawning> wonder how yours compares with mine
19:07:47 <GeKo> mikeperry: yeah, I was more wondering about the soft launch strategy
19:08:02 <dgoulet> Yawning: (#tor-project, TBB meeting ongoing)
19:08:18 <Yawning> (oops, my bad)
19:08:39 <GeKo> as we probably want to get the release notes widely circulated and all the people might start downloading the full bundle as they con't get updated
19:08:48 <GeKo> *don't
19:09:17 <GeKo> especially if we write USABILITY!11!!
19:09:40 <mikeperry> can we advertize a recommended update that doesn't actually throw a popup or other notification?
19:11:09 <GeKo> what do you mean?
19:11:23 <mcs> mikeperry: I am not sure but will check. Do you mean an update they can get if they do an update check themselves but one that will not be shown automatically?
19:11:35 <boklm> If we do this soft launch, I think it will require a small change to the update_responses script to list 4.5 clients as "no update needed", so they are not proposed a downgrade to 4.0 which is the latest version on the channel
19:11:45 <mikeperry> well I guess it wouldn't help in the common case, because the "Check For Update" menu wasn't added to Torbutton until 4.5 anyway
19:12:28 * isabela step out for food but ping me if you need any help from my side on organizing and keeping the roadmap updated
19:12:35 <mcs> What is the worst thing that can happen if we do not do a soft launch?
19:13:00 <mikeperry> boklm: ah, good point
19:13:10 <mcs> I guess 4.5 is a bad release and we scramble to fix issues.
19:13:22 <mcs> (worst case?  not fun to scramble)
19:13:23 <GeKo> yes
19:13:40 <mcs> I think we had that experience with 4.0 to some extent.
19:14:01 <GeKo> yes, but chances a relow we hit such a windows crash bug with 4.5
19:14:04 <mikeperry> well, I think the real nightmare scenario is we break TBB 4.0 users somehow in the update, and they are then unable to update to a new release and have to all start with a new TBB download
19:14:31 <mcs> Do we have any statistics about how many people are running the alphas?
19:14:51 <mcs> Yes, not being able to update would be bad.
19:15:39 <GeKo> mikeperry: but that sceanrio is not prevented by the soft launch strategy
19:15:44 <mikeperry> we can ask weasel. we're going to want stats for things like #15456 after we release 4.5a5 anyway
19:16:45 <mikeperry> GeKo: it might, if the bug is present independent of if you use the updater to install 4.5 or download a full copy yourself
19:18:08 <GeKo> I see, I read "somehow in the update" as referring to our built-in updater
19:20:09 <mikeperry> well, we can continue to think about this depending on how 4.5a5 goes, ad what type of fixes we add to 4.5.0-stable
19:21:27 <mikeperry> in the meantime, how should we handle the signing for 4.5a5. we're now going to do the windows signing, yes? does that mean re-packaging the NSIS to sign everything inside it (all .exes and .dlls)? and then also the NSIS exe itself? or just the outer exe?
19:21:41 <mikeperry> for #3861
19:22:31 <GeKo> the plan currently is only the NSIS exe to tet the authenticode thing going
19:22:38 <GeKo> *get
19:23:27 <mikeperry> and Windows will be OK if the firefox.exe is not signed? does it track that a signed app installed it or something?
19:23:50 <GeKo> windows is fine with that as far as i can tell
19:24:24 <GeKo> not that I am aware of
19:24:37 <mikeperry> weird
19:25:38 <mikeperry> are there any tools to strip Windows sigs off of .exes?
19:26:04 <GeKo> I found some scripts and plan to check that tomoroow + update the doucmentation
19:26:07 <mikeperry> for verifyability against the build sha256sums?
19:27:20 <GeKo> yes
19:28:00 <mikeperry> ok, so I guess if you handle that, I will handle the MAR signing and individual package gpg signing?
19:28:34 <mikeperry> and we leave the sha256sums.txt files with the original build hashes, and provide unsign instructions (I'm guessing using osslsigncode?)
19:29:35 <GeKo> re mar signing and package signing: you could but I can do that tomorrow, too
19:30:27 <GeKo> I thought I could get the 4.0.6 out around noon my time and you could take care of the 4.5a5 which would split the load
19:30:54 <GeKo> and yes, we leave the sha256susm.txt with the original build hashes
19:31:31 <mikeperry> hrmm. how should we handle the .exe gpg signing?
19:31:37 <mikeperry> I think we need to sign the signed exes there
19:31:45 <GeKo> yes
19:32:29 <mikeperry> so I guess that means I just do the MARs for 4.5a5. and/or I handle 4.0.6?
19:33:31 <GeKo> I am fine with signing all the stuff and get 4.0.6 out and you do 4.5a5 modulo the signing
19:35:16 <mikeperry> ok, so that means prep the blog posts and maybe copy your signed stuff into place tomorrow?
19:35:35 <GeKo> yes
19:35:49 <mikeperry> I can do both blog posts. the 4.0.6 one needs to remind the 32bit OSX users this is their last release
19:36:22 <GeKo> sounds good: I do the signing + 4.0.6 and you the blog posts + 4.5a5
19:37:25 <mikeperry> ok, and to clarify I am signing nothing for 4.5a5, just making sure everything is in the right place
19:37:35 <GeKo> yes
19:38:30 <mikeperry> ok great, I hate signing. so much juggling stuff between offline computers.. so tedious. I was trying to be nice by offering to do some of it ;)
19:39:23 <GeKo> I had the same motivation :D
19:40:32 <GeKo> and the overhead is smaller if just one is doing the signing
19:40:33 <mikeperry> cool, thanks. I think we're set then. I will get to work on these blog posts
19:40:44 <mikeperry> yeah, you're right.
19:42:57 <mikeperry> I think that's it for this meeting then
19:44:34 <mikeperry> isabela: as for the roadmap, we're in good shape for all of the stuff through April I think (the 4.5-stable things). the mobile stuff with Nathan's name on it could use some coordination, but after we get 4.5-stable out
19:45:22 <mikeperry> once 4.5.0-stable is out, we'll revisit the rest of these items and make sure they all have tickets and are more clearly specified
19:46:00 <isabela> thanks mikeperry !
19:47:00 <mikeperry> alright, thanks everyone!
19:47:06 <mikeperry> #endmeeting *baf*