18:00:59 <GeKo> #startmeeting tor browser
18:00:59 <MeetBot> Meeting started Mon Aug 29 18:00:59 2016 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:59 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:05 <GeKo> hi all!
18:01:28 <GeKo> i hope at least some have made it to the meeting given all the oftc issues
18:01:35 <boklm> hi
18:01:36 <GeKo> let's get started
18:02:16 <GeKo> i guess i can go first today
18:02:55 <GeKo> i worked on the design doc and wrote a small fix for #19995
18:03:09 <GeKo> i spent some time to work on our signing infrastructure
18:03:37 <GeKo> and if all went well we can do releases without me being available in the future
18:03:50 <GeKo> i guess we test that (sort of) with the next alpha
18:04:16 <GeKo> i resumed work on #13893
18:05:23 <GeKo> i took a look at the patches in #19410, #19528 and #19459
18:06:08 <GeKo> and #15852 which got merged meanwhile
18:06:56 <GeKo> this week i plan to work on the design document, review the unix domain socket patches and work further on the EMET bug
18:07:26 <GeKo> apart from that the usual begin-of-the-month admin stuff resurfaces
18:07:31 <GeKo> that's it from me
18:09:08 * mcs will go next
18:09:17 <mcs> Last week, Kathy and I created patches for #14271 and #14272.
18:09:24 <mcs> We revised our patch for #19733.
18:09:30 <mcs> We made some small changes to our #15852 patch which GeKo merged into torbutton master (thanks).
18:09:37 <mcs> We reviewed some patches.
18:09:42 <mcs> Also, I finalized travel plans for the Seattle dev meeting. I will be there Sunday afternoon - Thursday evening.
18:09:48 <mcs> This week we will continue working on Unix domain socket support, e.g., #14273 and maybe we will look at #19646 as well.
18:09:50 <GeKo> neat
18:09:59 <mcs> We will be away from keyboard this Friday (September 2nd) through next Tuesday (September 6th).
18:10:04 <mcs> That means we will miss next week’s meeting even if it is delayed by a day.
18:10:10 <mcs> That’s all for now.
18:11:28 <GeKo> who is next?
18:11:33 * boklm will go next
18:11:43 <boklm> This past week I investigated #12736 and I started working on #20018
18:11:55 <boklm> This week I'm planning to update release process doc for #19410, make a revised patch for #19528, and work on #20018 and #19067
18:12:12 <boklm> That's it for me
18:13:13 * arthuredelstein can go
18:13:32 <arthuredelstein> Hi, everyone. This past week I worked on #19459. I proposed a patch, but now found a problem with it on Linux. There are some reflow events that happen before the window is drawn to screen, which makes it very hard to control the final contentWindow dimensions. This week I will continue to work on this patch.
18:14:16 <arthuredelstein> Also this week, I worked on reviewing some isolation patches that our Mozilla friends are uplifting, including https://bugzilla.mozilla.org/show_bug.cgi?id=1264593, https://bugzilla.mozilla.org/show_bug.cgi?id=1264567, https://bugzilla.mozilla.org/show_bug.cgi?id=1289319
18:14:35 <arthuredelstein> They are making rapid progress!
18:14:50 <arthuredelstein> (During the dicussion I would like to bring up a question the Mozilla folks have been asking about.)
18:15:08 <arthuredelstein> That's it for me.
18:15:30 <GeKo> https://bugzilla.mozilla.org/show_bug.cgi?id=870346#c1 might be of interest to you
18:16:04 <arthuredelstein> That does look relevant
18:16:05 <GeKo> arthuredelstein: and this + my experience with the resizing code made me quite skeptic that we can solve this from JS land
18:16:12 <GeKo> but we'll see I guess ;)
18:16:25 <arthuredelstein> You may be right, although I'm not sure how to solve it from C++ either!
18:16:40 <GeKo> yeah.
18:16:57 <GeKo> this is actually the reason why we have the mutation observer in torbutton right now
18:17:07 <arthuredelstein> Basically, I can make it work on all platforms without a mutation observer, but the user sees a resize.
18:17:15 <arthuredelstein> It can be a smallish resize, but that's still ugly.
18:17:38 <GeKo> because the https-e icon resizes the window after adding the button to the toolbar
18:18:07 <arthuredelstein> I hadn't even tested in with https-e...
18:18:10 <arthuredelstein> s/in/it
18:18:13 <GeKo> (actually it resizes the window slightly by adding the button to the toolbar
18:18:16 <GeKo> )
18:18:24 <arthuredelstein> Does that happen after the window has been painted to screen?
18:18:25 <GeKo> but maybe the new icon solves this?
18:18:47 <GeKo> not sure anymore
18:19:50 <GeKo> anyway, if we get the same behavior with the patch moved to firefox that would be fine i guess
18:20:03 <arthuredelstein> Some of the existing Mozilla code (TabsInTitleBar.js) already uses mutation observers, so I wouldn't rule it out as acceptable.
18:20:20 <arthuredelstein> (I mean for chrome window layout.)
18:20:25 <GeKo> yes
18:22:03 <GeKo> okay, is anybody else here for the status update?
18:23:16 <GeKo> alright, let's move on to the discussion phase
18:23:30 <GeKo> i don't have anything beyond the usual sponsorU reminder
18:23:44 <GeKo> arthuredelstein: you had something for discussion?
18:24:04 <arthuredelstein> Yes -- the Mozilla engineers have been asking about our strategy of releasing on ESRs.
18:24:37 <arthuredelstein> They are interested to know if, in the future, if they succeeded in uploading all or nearly all of our patches, if we would transition to following the main release channel instead of ESRs.
18:25:08 <GeKo> hm
18:25:11 <arthuredelstein> In part this might affect Mozilla priorities.
18:25:23 <GeKo> in which regard?
18:26:03 <arthuredelstein> In terms of which patches to focus on uplifting, and perhaps other things that I don't fully understand.
18:26:18 <huseby> what don't you understand?
18:26:21 <huseby> maybe I can explain better?
18:26:25 <GeKo> o/
18:26:46 <arthuredelstein> huseby: Yes, that would help! :)
18:27:01 <GeKo> huseby: hi and thanks for doing all the amazing patch uplift work
18:27:07 <GeKo> really appreciated :)
18:27:10 <huseby> GeKo: sure :)
18:27:15 <huseby> so here's what we're looking at
18:27:38 <huseby> it seems likely that we're not going to get *all* of the patches uplifted before 52 (the next ESR) forks from central
18:27:55 <huseby> which means there are two paths to follow
18:28:34 <huseby> 1) if TBB stays on ESR, we need to work with you to prioritize which patches do make it into 52 since we'll have to wait another year before you get the rest.
18:29:12 <huseby> 2) if TBB commits to moving to release, then it doesn't matter because once you move to release, you'll be getting the patches on our regular release cycle
18:29:37 <huseby> my personal opinion is that you should move to release
18:30:01 <huseby> AFAIK, you chose to use ESR because you were going to be maintaining a heavy patch load and rebasing was easier
18:30:12 <huseby> ESR release pace at once-per-year allowed you to keep up
18:30:19 <huseby> but now that patch load is approaching zero
18:30:20 <GeKo> that is one of the main reasons
18:30:23 <huseby> fast approaching zero
18:30:26 <GeKo> but not the only one
18:30:54 <GeKo> the other big one is that we need time for feature reviews and write new patches
18:30:54 <huseby> ok, good :) see this is why we're having this conversation :)
18:31:15 <huseby> GeKo: maybe we should do a joint pros/cons session at the dev meetup?
18:31:16 <GeKo> and it turned out that we basically started esr45 with the same amount of patches than we started with using esr38
18:31:27 <GeKo> despite stuff getting merged meanwhile
18:31:48 <GeKo> + we have one engineer less on the team than usual
18:32:21 <GeKo> it seems this indicates 1)
18:32:27 <GeKo> alas
18:33:01 <GeKo> we could have such a session at the dev meeting
18:33:43 <GeKo> i guess we are happy to talk about this and we could prepare some pro/cons write-up for discussion
18:34:00 <arthuredelstein> I think it's definitely worth reviewing.
18:34:04 <GeKo> but i fear we are not there yet
18:34:08 <huseby> GeKo: my main concern is that ESR's only get the most critical security fixes
18:34:29 <huseby> there are quite a few security fixes that are serious, but don't rise to the level where we include it in the ESR
18:34:36 <GeKo> that is one point
18:34:47 <huseby> and I worry that some of the serious-but-not-serious-enough bugs would/could expose your users.
18:34:56 <GeKo> yes
18:35:25 <huseby> being on release would alleviate much of that worry
18:35:25 <GeKo> on the other hand all the time i see the advisories for release i am glad we are on ESR :)
18:35:43 <GeKo> meaning we don't have to worry about those in addition to the ones for ESR
18:36:53 <mcs> Having some data would aid this discussion, e.g., how many patches will not be uplifted. are more security issues associated with new Firefox features, etc.
18:37:14 <mcs> (as opposed to new holes in old code)
18:37:27 <GeKo> i guess this could be part of the write-up for the discussion or part of the session itself
18:37:38 <GeKo> and sounds very reasonable to have
18:37:47 <mcs> vi x
18:37:58 <mcs> oops :)
18:38:17 <huseby> GeKo: except, those advisories might also be affecting ESR but not getting fixed in ESR :)
18:38:39 <GeKo> well, i was only talking about the things i see with respect to new features
18:38:43 <huseby> mcs: https://wiki.mozilla.org/Security/Tor_Uplift/Tracking
18:38:51 <huseby> we are focusing on first party isolation
18:38:58 <huseby> that's the only thing we've committed to for the next ESR
18:39:07 <huseby> but I've been sneaking other patches in there too
18:39:24 <huseby> I'm about to land the patch for disabling the "this plugin is disabled" barrier
18:39:29 <huseby> things like that
18:39:36 <huseby> there's work on font enumeration happening
18:39:40 <huseby> on the side
18:39:50 <huseby> and a couple of our interns landed the disabling mathml and svg patches
18:40:45 <GeKo> huseby: there are other moments i am really glad about that we are staying on ESR
18:41:13 <GeKo> if you look at fixup releases you'll see that release has much more of them than ESR
18:41:28 <GeKo> which would likely mean  we'd need much more of them, too
18:41:38 <GeKo> and these are really expensive for us
18:42:08 <huseby> GeKo: that makes sense.
18:42:11 <arthuredelstein> What is the biggest expense involved in fixup releases?
18:42:15 <huseby> we're not trying to push you either way
18:42:33 <huseby> just want to know sooner rather than later which path you want to take
18:42:36 <huseby> if it is #1
18:42:41 <GeKo> oh, and i was glad we stayed on esr38 while mozilla struggled to get (esr)45 into shape
18:42:44 <huseby> then we need to plan on prioritizing this week or next
18:42:53 <GeKo> IIRC it took 3 follow-up releases
18:43:05 <GeKo> and there was still fallout in firefox 46 and 47
18:43:55 <GeKo> arthuredelstein: that it takes focus away from other tasks and takes a bunch of time to prepare and sign everything and write blog posts etc
18:44:23 <GeKo> huseby: so, i am pretty sure for esr52 it will be #1
18:44:34 <GeKo> we might be in better shape for esr59
18:44:55 <huseby> GeKo: roger
18:45:00 <huseby> I'll report back on that
18:45:10 <GeKo> thanks
18:45:32 <huseby> GeKo: how can we best do the prioritization?
18:45:44 <huseby> I can give you a list of the patches that most likely *won't* make esr2
18:45:47 <huseby> esr52
18:45:53 <GeKo> you mean with the firt party isolation area?
18:46:00 <GeKo> or in general?
18:46:04 <GeKo> *within
18:46:13 <huseby> first party isolation is supposed to  make it
18:46:20 <huseby> we're trying really hard to make that  happen
18:46:28 <GeKo> all of it? wow
18:46:32 <GeKo> that would be neat
18:46:32 <huseby> it's the remainder that we're talking about
18:46:45 <huseby> (maybe, it's based on origin attributes....don't count those chickens yet)
18:47:03 <arthuredelstein> GeKo: Makes sense (re release expense)
18:47:10 <GeKo> okay. if you can give me the list of patches you have on your radar and are wondering about
18:47:20 <GeKo> then i'll have a look
18:47:48 <GeKo> we could talk about them on the meeting next week
18:48:11 <GeKo> then everybody has a say and can help
18:49:41 <GeKo> huseby: maybe sending this to tbb-dev would be the right thing and we could already start a discussion there?
18:51:18 <GeKo> okay. do we have something else to dicuss?
18:51:44 <sukhe> I can go next if everyone else is done :)
18:51:58 <GeKo> ah, hi, sure :)
18:52:29 <sukhe> hi. so we are quite close to the Tor Messenger release with the updater... we would like to get the Windows and OS X builds signed with the respective certs
18:53:04 <sukhe> can I just complete the builds and point them to you and then you can sign and upload and we release them?
18:53:14 <GeKo> we can do this.
18:53:23 <sukhe> perhaps we can decide a more streamlined strategy later but for now we can just do this
18:53:53 <GeKo> yeah. boklm can do the windows stuff
18:54:01 <GeKo> and soon the os x stuff as well
18:54:14 <GeKo> and otherwise ping me and we'll get this done
18:54:21 <sukhe> ok great, thanks. I will ping you when we are ready
18:55:37 <sukhe> that's it from me. we will be finalizing the builds today and plan to release by Wednesday (flexible if we can get the builds signed)
18:55:46 <GeKo> exciting. i hope it goes well :)
18:56:02 <sukhe> yeah!
18:56:13 <sukhe> the updater was much needed
18:56:36 <GeKo> ok. anything else for today?
18:57:37 <GeKo> thanks everybody *baf*
18:57:38 <GeKo> #endmeeting