13:51:00 <nickm> #startmeeting
13:51:00 <MeetBot> Meeting started Wed Jan 28 13:51:00 2015 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:51:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:51:07 <nickm> hi!   last tor dev meeting of january
13:51:25 <nickm> I got distracted trying to find a calendar sync solution that doesn't tie me to google
13:51:34 <nickm> and when I looked up, it was now
13:51:43 <nickm> So, last dev meeting of January!
13:51:49 <nickm> nominally, 3 days left to merge features.
13:53:43 <dgoulet> 110 ticket for 0.2.6, 15 in need_review
13:56:12 <msvb-lab> nm -C libxul.so | grep -i GetCookieStringInternal
13:56:17 <msvb-lab> ...should give:
13:56:20 <msvb-lab> 00000000009d8514 t nsCookieService::GetCookieStringInternal(nsIURI*, bool, bool, unsigned int, bool, bool, nsCString&, nsCString&)
13:56:34 <msvb-lab> ...but with the gitian bundle build:
13:56:41 <nickm> dgoulet: I think most of those will not get into 0.2.6. :)
13:56:48 <msvb-lab> nm: libxul.so: no symbols
13:56:49 <nickm> I wonder if I shouldn't add a few extra days, though.
13:56:52 <msvb-lab> ...dead end.
13:57:01 <nickm> I guess we'll see.
13:57:20 <dgoulet> nickm: well seems it should be bug triage soon :)
13:57:38 <nickm> yeah.  we need clearer criteria IMO for this stage.
13:57:59 <nickm> I'm included to try to squeeze the guard improvements (asn's guard selection logic and my crazy hopes for #13989) in if we can
13:58:11 <msvb-lab> GeKo: Do you still have object files for the bundle you sent me?
13:58:13 <msvb-lab> ...or another idea to forensically look inside libxul.so?
13:58:43 <dgoulet> nickm: agree
13:58:49 <nickm> they might need to go in after the deadline though.
13:59:02 <dgoulet> and the proposal you sent yesterday, would it make sense to get it in?
13:59:03 <nickm> I think we can consider anything that's mostly implemented by the end of the month for after deadline.
13:59:10 <nickm> that's for 13989
13:59:12 <msvb-lab> GeKo: I think you mentioned that you were sure the patch code was in the binary, or did I misunderstand that?
13:59:16 <dgoulet> nickm: oh right
14:00:04 <nickm> I hope I can get it implemented, but this week is pretty crazy
14:00:43 <nickm> I guess I should send it to tor-dev first too
14:01:10 <dgoulet> send what? the proposal v2?
14:01:15 <dgoulet> patch?
14:01:54 <nickm> the proposal i emailed people yesterday, plus any changes people recommended
14:06:32 <msvb-lab> GeKo: If we have an hour or so :-( then gdb(1) can indicate if the patched GetCookieStringInternal is used or not.
14:07:08 <GeKo> https://pastebin.mozilla.org/8400232
14:07:40 <GeKo> the bundle is stripped and all the stuff you need is in the *debug.zip
14:07:46 <asn> i still haven't heard from teor about the unittest break of #9321 :(
14:07:55 <msvb-lab> GeKo: The signature is correct, this is bizarre.
14:08:03 <asn> i have a suspicion on what might be breaking, but I want to test it and I don't have mac os x i386 here.
14:08:19 <dgoulet> asn: last time I heard of him, he was really busy :S
14:08:22 <asn> yeah :(
14:08:24 <asn> i don't blame him.
14:08:29 <asn> today i finish from uni stuff.
14:08:37 <asn> tomorrow I will try to fix that branch.
14:08:39 <asn> and have it ready.
14:09:27 <nickm> ok
14:09:30 <dgoulet> ah yeah athena ! #11485, I shall review that
14:09:58 <asn> i wish i could give jenkings a git branch and it would compile it in all its archs
14:10:01 <asn> and tell me the results
14:10:06 <nickm> so we're getting close to that tense end-of-release time, where we mess up the next release by delaying too much or too little
14:10:13 <asn> :)
14:10:54 <asn> i think also sysrqb mentioned something about his "all relays are now dirguards" branch being ready
14:10:59 <asn> and trying to fit it before the feature freeze
14:11:03 <asn> not sure if you guys are aware
14:12:07 * dgoulet trying to find the ticket
14:12:34 <asn> maybe #12538
14:12:46 <asn> s/dirguards/dircache
14:12:54 <dgoulet> ah yep!
14:13:28 <sysrqb> yup
14:13:40 <sysrqb> i running a chutney test net now
14:13:49 <sysrqb> i should update the ticket within the next few hours
14:13:57 <nickm> hm. is it in needs-review?
14:14:00 <nickm> asn: ^
14:14:10 <sysrqb> i tihnk still needs-revision
14:14:20 <nickm> ok
14:14:23 <sysrqb> i'll change it when i add a new comment
14:14:48 <dgoulet> so should we triage the 110 remaining bugs which will give us a clearer picture of what to do in the next... 3 days :P?
14:14:56 <nickm> heh.
14:15:14 <dgoulet> (or schedule a triage time)
14:15:52 <nickm> I think that we should decide on a policy and then do triage a little post-feature-freeze
14:16:45 <nickm> Here's a possible policy: "we fix regressions, we fix actual bad security bugs, we merge trivial changes."
14:18:02 <dgoulet> that's post feature freeze or in the next 3 days?
14:18:35 <nickm> post-freeze.
14:18:42 <dgoulet> sounds good to me
14:18:53 <nickm> I think that in the next three days we proceed as normal, but maybe allow a couple of things we really want to land in the week after?
14:19:02 <nickm> or should I go "no, no, it's a freeze!"
14:19:11 <sysrqb> and freeze is set as 01 Feb?
14:19:28 <dgoulet> I think it's fine that we decide now (pre-post-freeze :) what is important
14:19:40 <msvb-lab> GeKo: Is the debug.zip somewhere in https://people.torproject.org/~gk/testbuilds/ ?
14:19:43 <msvb-lab> I'm not getting anywhere trying to gdb(1) the stripped so files.
14:19:49 <nickm> sysrqb: yes.
14:20:18 <nickm> dgoulet: I really want the relevant guard fixes. (asn's stuff plus some branch I do for #13989).  Those should help security a great deal.
14:20:21 <sysrqb> ok
14:20:39 <nickm> I think they're worth doing even the week after.
14:20:49 <nickm> though obviously this week is nice if possible.
14:20:49 <dgoulet> nickm: agree! so maybe we should list the ticket somewhere that are "features" and "ok post freeze"
14:21:24 <nickm> let's use 026-triaged-3
14:21:39 <nickm> or wait maybe something better
14:21:55 <nickm> "unfrozen"
14:22:34 <weasel> thawed :)
14:22:37 <dgoulet> well what about all "feature" that can't make it in 0.2.6 are flagged 0.2.7 ?
14:22:56 <nickm> two points there
14:23:32 <nickm> first, what if we do this to all features now, and all non-regression non-security bugs mid-feb?
14:23:57 <nickm> second, what if we put some in 0.2.7 and some in 0.2.??? ?
14:24:22 <nickm> [experience suggests that if we are deferring a ticket from release A, it might not go into A+1 either]
14:24:40 <dgoulet> nickm: agree on both
14:25:04 <dgoulet> triage feature now so we only keep the one we want in 0.2.6 and the rest is differ to ???
14:25:27 <nickm> well, do we have any programmers who don't have more than enough to program by end-of-month?
14:25:35 <nickm> if not, why triage right now?
14:25:57 <dgoulet> because we don't know which feature we want to accept in 0.2.6 ?
14:28:20 <nickm> well, we want to try to review everything with code.
14:28:49 <nickm> and we know about what we're coding between now and 1Feb...
14:29:02 <dgoulet> fair enough
14:30:08 <nickm> I guess there's nothing stopping us from triaging stuff we *know* isn't going in...
14:30:25 <dgoulet> right
14:30:40 <dgoulet> so to summarize, on 1 feb we triage features
14:30:50 <dgoulet> mid-feb we triage "defect"
14:30:51 <dgoulet> ?
14:30:54 <nickm> well, we can triage features we know nobody is working on today, I guess.
14:31:00 <nickm> no harm in that
14:31:11 <dgoulet> indeed
14:31:20 <nickm> And I guess we can triage defects early too, to identify stuff worth looking at.
14:31:35 <nickm> though I really want to focus on regression or security-bug or trivial-fix.
14:31:58 <nickm> One challenge is that you can argue that nearly every new security feature is actually a fix for a security bug.
14:32:02 <nickm> I wonder what to do about that.
14:32:31 <dgoulet> how many security feature do we have in the pipeline?
14:32:52 <dgoulet> (or which one are those, is there like a "security" keyword)?
14:33:24 <nickm> we don't have a security keyword
14:33:31 <nickm> arguably, all the unix-sockets stuff is security
14:33:34 <nickm> the guard stuff sure is
14:34:51 <dgoulet> security? #9476
14:35:17 <nickm> So, that _is_ security-related.......
14:35:31 <nickm> .......but I don't want to call it "the kind of thing that goes in after freeze"
14:35:36 <nickm> though we can IMO call it unfrozen
14:35:48 <nickm> the code is right; we just need to decide if it's safe to do
14:36:55 <nickm> it's security, but it's not a security _bug_, if you see what I mean
14:36:59 <dgoulet> yup sure
14:40:04 <nickm> hey, I bet if we look over things for like an hour after the meeting, we can triage some things right now though.
14:40:09 <nickm> shall we end the meeting and do that?
14:40:12 <dgoulet> switching to one guard should be in 0.2.6? (looking at #11480)
14:40:13 <nickm> it could be a nice break for me
14:40:16 <dgoulet> nickm: sure yeah
14:40:17 <nickm> imo yes
14:40:22 <nickm> #endmeeting