13:30:32 <nickm> #startmeeting
13:30:32 <MeetBot> Meeting started Wed Mar 11 13:30:32 2015 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:30:32 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:30:34 <nickm> hi all
13:30:37 <nickm> let's check in?
13:30:38 <dgoulet> hello
13:30:43 <isabela> hi
13:30:48 <nickm> I see athena dgoulet Yawning isabela nickm...
13:31:13 <Yawning> hi
13:31:58 <Yawning> let me get some caffine real fast
13:32:19 <nickm> so, let's do quick who's on what updates.
13:32:38 <nickm> I'm looking at all the stuff I need to write in the next 20 days for sponsor S and being a bit overwhelmed; that's going to be a lot of my time.
13:32:47 <nickm> I've got 0.2.6.4-rc out, though, and that's good
13:32:52 <Yawning> (right, caffine obtained)
13:33:23 <athena> been away a couple days post-valencia; about 75% of the way through auditing our strlcat/strlcpy calls per request of nickm last week; haven't found anything egregiously bad yet
13:33:29 <nickm> great
13:33:51 <nickm> I found that the one case I thought I found wasn't what I thought, and it was in fact an Apple bug instead: #15205
13:34:30 <nickm> who else is up to something?
13:34:42 <dgoulet> I'm up to something
13:34:46 <Yawning> uh, poked at #6411 some more
13:34:55 <Yawning> it has documentation now
13:35:08 <Yawning> unless someone complains I'm going to rebase/squash my branch and seek review
13:35:23 <Yawning> but I'll give it a day or so before I do that
13:35:42 <athena> nickm: thanks for letting me know
13:35:50 <Yawning> then pt stuff, the wide block cipher investigation, and reviewing the ed id key branch
13:36:02 <Yawning> (in no particular order)
13:37:30 <nickm> athena: (to be clear, it's still worth auditing those IMO. Just because the one case I thought I found wasn't there doesn't mean that we're in the clear :) )
13:37:45 <Yawning> I was also informed that really bad things happen when a single tor instant tries to run lots of HSes
13:37:50 <nickm> Yawning: Cool! Do you think we can call this S or U or O or something?
13:37:55 <Yawning> might look into that
13:38:03 <Yawning> which
13:38:08 <nickm> The ADD_ONION things
13:38:14 <Yawning> I dunno
13:38:20 <Yawning> who likes hidden services?
13:38:49 <Yawning> arma hinted at dire things happening if I left a 2 line python script adding onions in a while loop
13:38:56 <nickm> R does, but we're on stop-work for R.  We can plausibly call this S though, since it helps testing networks.
13:39:43 <dgoulet> I guess we can sping this that way: S yes, because with that we can easily test/scale HS to support LOTS of hs in a single tor instance
13:40:01 <nickm> Yawning: also, did you get feedback from atagar on your specs?  He's usually pretty good at spotting spec holes
13:40:20 <Yawning> not yet, arma did a pass through it
13:40:45 <Yawning> I wrote the documentation earlier today so, I don't think most people had a chance to see it
13:40:56 <Yawning> (mail was sent to tor-dev@, so)
13:41:23 <nickm> ok.  I think atagar's review there should be pretty helpful.
13:41:35 <dgoulet> Yawning: I read it this morning, want to take a second look before comment
13:41:37 <nickm> anything more?  is dgoulet next?
13:42:51 <dgoulet> so yeah I'm finishing the refactoring of the rendclient fetch v2 desc code so we can fetch descriptor ID... this is R but maybe could get squeeze in U or S, arma had a convincing sentence about it last week
13:43:03 <nickm> it definitely fits in S
13:43:17 <dgoulet> mostly for our hs health tool so S yes
13:44:01 <dgoulet> it turned out a bit more difficult that I anticipated, rend_data_t is pretty bolted in the "fetch code chain" and if you don,t have an onion_address in there, things fall apart
13:44:15 <dgoulet> I have something that works now, just need to clean it
13:44:19 <nickm> right.  this is _not_ well factored code as it stands
13:44:21 <nickm> awesome
13:44:49 <dgoulet> nickm: that's going to be a relatively big patch for #14847 with multiple commits (i tried my best to break it down)
13:45:04 <dgoulet> but I expect to day I'll be able to submit it
13:45:40 <dgoulet> apart from that, my next goal is review identify key patch (12...)
13:45:58 <nickm> #12498
13:46:02 <dgoulet> yes that one!
13:46:06 <dgoulet> and Yawning add_onion also
13:46:09 <nickm> I should shake the last bugs out of it
13:46:30 <dgoulet> I'll wait until status report are done to discuss more stuff
13:46:32 * dgoulet done
13:47:12 <nickm> ok. anybody else?
13:47:23 <nickm> If not we can move on to discussions and stuff-that-needs-to-get-done
13:48:25 <dgoulet> I have two things in mind here, 1) chutney2 design, 2) and is there any way I can convince nickm for #15220 :D
13:48:41 <Yawning> dgoulet: I can change the numberings on the commands in my spec based on which of our patches gets merged first
13:48:43 <Yawning> btw
13:48:51 <dgoulet> Yawning: yeah same here, no biggy
13:49:13 <nickm> yeah, I need help with chutney2.  Maybe I should do the summary now and we should talk about it after this meeting
13:49:32 <nickm> the summary is that I want chutney to script many many more things than Tor, and support many more test scenarios than it currently does
13:49:32 <Yawning> also, nickm's "open-by default" feels scary argument for #15220 is what I said in IRC last nigt ;_
13:49:46 <dgoulet> Yawning: not on the ticket, it never happened :P
13:49:51 <nickm> This will require some rethinking and recoding
13:50:02 <nickm> dgoulet: hey, IRC exists man :)
13:50:06 <dgoulet> :)
13:50:10 <dgoulet> nickm: ack (chutney2)
13:50:33 <nickm> this requires a design and an alpha prototype by the end of the month.
13:50:42 <nickm> and I've been (my own fault) flying solo on it.
13:50:43 <Yawning> owa
13:50:50 <Yawning> chutney2?
13:50:52 <Yawning> eeep
13:51:10 <nickm> other stuff I need to hand over by end-of-month for S are quick metrics on where our code most needs tests and least wants tests;
13:51:23 <nickm> drafts for imporovements to the controller interface to support better testing;
13:51:46 <nickm> and a draft design for breaking Tor into better decoupled modules.
13:51:51 <dgoulet> wow
13:51:57 <Yawning> wow
13:52:24 <dgoulet> nickm: I'm on U right now but sounds like S would need help ... :)
13:52:40 <nickm> I estimate that I can do drafts of the draft designs in about a 1.5 days each.  Comments on them would help make them better.
13:52:45 <nickm> Code scrutiny should take a day
13:52:54 <nickm> This leaves me with chutney2 as my biggest timesink I think
13:53:46 <nickm> Also, we should soon come up with a timeline for 0.2.7 and triage tickets for it.  Not sure how best to do that.  Previously, it's eaten a lot of time to go over ticket by painstaking ticket, and we always wind up throwing things out at the last minute
13:54:31 <Yawning> do we know what our big must have featuers for 0.2.7.x are?
13:54:47 <Yawning> (there was a gigantic list on a wall at valencia if I recall correctly)
13:54:48 <nickm> no :)
13:55:02 <nickm> we have some must-do-for-October things for U, I believe
13:55:13 <dgoulet> yeah still early, just for hs stats, we are in the dark for an aggregation system that *might* get in 0.2.7 or not...
13:55:13 <nickm> and more deliverables for S in October, I suspect
13:56:37 <Yawning> oh I missed something from my todo list
13:56:40 <nickm> but since we aren't tied to a timeline for releasing 0.2.7, those could be in-0.2.7 or not
13:56:43 <nickm> Yawning: ok?
13:56:44 <Yawning> finish the tentp v0 draft
13:56:46 <Yawning> >.>
13:56:47 <nickm> oh yeah
13:57:03 <isabela> I can help coordinate the triaging for 0.2.7
13:57:18 <isabela> btw, this stuff is at your roadmap: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor
13:57:38 <Yawning> because the various people I talked to it external to tor at VLC made positive noises at the concept
13:58:19 <nickm> woo, readable.
13:58:59 <nickm> it would be cool if more of those items had people on them. :)
13:59:03 <dgoulet> isabela: oh wow a superb well formatted roadmap!
13:59:17 <nickm> especially for the next month or two.
13:59:25 <isabela> I will be sending a not to the different dev teams asking them to update the blank cells in those tables :)
13:59:38 <isabela> yeah, specially for march and april
13:59:51 <nickm> Triaging and scheduling 0.2.7 is pretty crucial IMO.  If we're aiming for an August freeze, we should probably have a lot more things aimed for it.
14:00:20 <dgoulet> "Identify IPv6 state" <-- we can't squeeze this in a Sponsor?
14:00:35 <nickm> probably but not sure who
14:00:35 <dgoulet> because I'm going to be of a good help for that, I need to deploys a tor network on an ipv6 only network in the next month ;)
14:00:46 <dgoulet> (on my free time)
14:01:23 <Yawning> IPng^h^hv6 will be widely deployed any day now, so it needs testing
14:01:26 <Yawning> ???
14:01:44 <dgoulet> Yawning: ?
14:01:48 <isabela> nickm: are the tickets we will triage tagged in anyway?
14:02:00 <Yawning> dgoulet: it's testing related! :P
14:02:35 <nickm> isabela: the milestone "Tor: 0.2.7.x-final" has all the stuff that we had tentatively assigned to 0.2.7.x.
14:02:43 <nickm> There  may be sponsored deliverables  without tickets.
14:02:45 <dgoulet> Yawning: indeed
14:02:45 <isabela> nickm: perfect, thanks!
14:03:14 <nickm> The milestone "Tor: 0.2.???" has a bunch of stuff that we agreed is probably a good idea  to do when we can, but we didn't put it in 0.2.7
14:03:37 <isabela> ok
14:03:37 <nickm> Nothing has time estimates; sponsored vs unsponsored deliverables aren't well marked; etc etc
14:03:43 <Yawning> does isabela know about the "lorax" keyword?
14:03:48 <nickm> ah
14:03:51 <isabela> i dont
14:03:58 <dgoulet> nickm: where is your document you wrote on the wiki about ticket keyword convetion?
14:04:02 <nickm> the "lorax" keyword is a reference to _The Lorax_ by Dr Seuss.
14:04:08 <nickm> dgoulet: I'm not sure I wrote one
14:04:13 <dgoulet> nickm: oh yes you did
14:04:20 <dgoulet> I saw it with my own eyes! :)
14:04:26 <nickm> the quote is "Unless someone like you cares a whole awful lot / Nothing is going to get better. It's not!"
14:05:09 <nickm> https://trac.torproject.org/projects/tor/wiki/org/process/TorOnTrac
14:05:18 <dgoulet> that one :)
14:05:37 <nickm> lorax generally means "We would take a patch for this, but we aren't planning to write one."
14:05:55 <isabela> nice
14:06:38 <isabela> thanks for sharing this link
14:06:47 <nickm> thanks to dgoulet for reminding me it existed
14:08:02 <isabela> so maybe we can have a first run on triagging stuff to 0.2.7 next week and another one latter to make sure it has all we want?
14:08:17 <nickm> sounds plausible. What should we do between now and then to make it go well?
14:08:18 <isabela> I can help coordinate that (and will be pinging some of you on the way)
14:08:25 <Yawning> it kind of needs to be an ongoing process
14:08:27 <nickm> In the past, triage has taken a few days and a lot of time
14:08:40 <Yawning> since random things have a tendancy to lurk out of the darkness and catch us by suprise
14:08:50 <nickm> "no plan survives contact with the enemy"
14:09:10 <Yawning> "no plan survives contact with OpenSSL"
14:09:26 <isabela> i would suggest to label candidate tickets with the version label... then we have a list by next week and the exercise would be to remove the label from things we don't want to add
14:10:10 <isabela> Yawning: I agree, somethings will probabl change in a month from now... is an ongoing thing for sure
14:10:50 <isabela> but I am open to whatever you guys prefer since is my first time doing it :)
14:11:15 <nickm> ok.  So goals are to make sure everything we need to do by date X has a ticket, and make sure that everything in 0.2.??? that one of us wants to do goes into 0.2.7, and then we start kicking stuff out?
14:11:53 <dgoulet> sounds reasonable to me ^
14:12:01 <isabela> yep, sounds like a plan
14:12:38 <nickm> and we make sure sponsored stuff is tagged with the sponsor.
14:12:59 <nickm> I'll volunteer to do the ticket creation for S and U up through October?
14:13:28 <nickm> Note that we are not required to have the stuff that we've promised in a stable release -- it's only required to be _built_.
14:13:43 <nickm> Though obviously it'd be great if we could have it in a stable release. :)
14:14:22 <nickm> anybody volunteer to look through 0.2.??? ?
14:15:43 <dgoulet> I can give it a shot but not sure i'm the right person to be able to fully triage those :S ...
14:15:59 <nickm> also, it would be good if somebody could go over the roadmap and make sure it's right. :)
14:16:11 <nickm> like, cross-referencing to actual sponsor docs
14:16:37 <isabela> nickm: I can help with that, I pinged karen to get more info from sponsor docs
14:16:55 <isabela> nickm: I only have sponsorR doc
14:17:01 <nickm> great. I also know that Stephen may have a hold of these if Karen is busy.
14:17:09 <nickm> #action I'll send you U today
14:17:19 <isabela> dgoulet: is a pre-triagge you could pick up as many things you consider important
14:17:49 <dgoulet> isabela: right, my knowledge of the entire code base is limited so I'll do what I can at least that would be something :)
14:18:04 <isabela> thanks!
14:18:06 <nickm> sounds good to me
14:18:31 <isabela> is it ok to use this time for the triage meeting next week?
14:18:37 <isabela> or should I organize a new meeting for that
14:18:42 <nickm> I don't object; does anybody else?
14:18:52 <dgoulet> hrm
14:18:53 <nickm> We should maybe grab a couple of times; these things often go loooooong
14:19:13 <dgoulet> can we keep sometimes in this meeting for general discussion about little-t tor, after that I don't mind doing triage
14:19:20 <dgoulet> some time*
14:19:42 <isabela> ok dgoulet ack / nickm I will send a poll for a 'second round'
14:20:25 <nickm> sounds good to me
14:21:04 <isabela> #action poll for triage second round
14:21:15 <nickm> anything more for this meeting? It's been almost an hour, and we often run out of steam around then.
14:21:28 <dgoulet> I do have one little question (technical)
14:21:31 <nickm> is it worthwhile to try to do any time/work estimates on this stuff?
14:21:35 <nickm> dgoulet: shoot!
14:22:15 <dgoulet> nickm: fetching with a descriptor id, does it makes sense to try all replicas or just a random one?
14:23:09 <nickm> I'd suggest that the default should be "do what a client would do", with options to do something different.
14:23:25 <nickm> These options don't need to get built in v1 of this, but it's a good idea to design them.
14:23:35 <nickm> IMSomewhatHO
14:23:41 <dgoulet> that,s the current state, just what the client is suppose to do
14:24:01 <nickm> oh.  You're asking whether the client's current behavior is sensible?
14:24:06 <dgoulet> however a fetch by desc id is "new" for the client because usually we compute the desc_id with the .onion thus trying all replicas for it
14:24:55 <dgoulet> in my case, we *only* have a desc_id thus no way of knowing what server should be used so closest to the current client behaviour would be try all six?
14:25:04 <dgoulet> even if it's the same desc_id for each fetch
14:27:08 <nickm> shall we continue this after the meeting? I think others jmight like permission to wander off for a minute or 2. :)
14:27:19 <dgoulet> ah sure
14:27:35 <nickm> #endmeeting