16:58:48 <nickm> #startmeeting network team, 11 June
16:58:48 <MeetBot> Meeting started Mon Jun 11 16:58:48 2018 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:58:48 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:58:51 <nickm> Hi folks!
16:58:58 <haxxpop> hi all !!
16:59:06 <haxxpop> long time no see :)
16:59:09 <nickm> https://pad.riseup.net/p/dahgDhEbEhxa is our pad this week
16:59:57 <dgoulet> hi
17:00:10 <nickm> hi dgoulet !
17:00:40 <isis> o/
17:00:45 <nickm> hi isis!
17:00:58 <asn> hello team! :)
17:01:09 <nickm> we've been 2 weeks without an online meeting; let's see how we're doing
17:01:49 <nickm> let's start with a look at our happy-fun roadmap (see link on pad)
17:02:19 <nickm> The most important stuff we should do this week, I think, is our 0.3.4 bugfixes
17:02:30 <nickm> if we have any assigned
17:02:50 <nickm> here are the 0.3.4 tickets: https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&milestone=Tor%3A+0.3.4.x-final&group=status&order=priority
17:03:17 <nickm> Note that there are 6 tickets in "new" without an owner
17:04:00 <nickm> if anybody thinks they can make progress on one of those, it would be great, especially if you don't have other stuff in 0.3.4
17:04:12 <nickm> I want to release another 0.3.3 this week, and too
17:04:45 <nickm> The tickets without an owner are #26094, #25976, #26269 ...
17:04:56 <nickm> ... #26300, and #26311 .
17:05:13 <nickm> (I'm skipping #26297 because it isn't really something we can do except by finishing the release)
17:06:19 <nickm> any feelback on current 0.3.4 assignments? any volunteers for remaining 0.3.4 stuff?
17:07:04 <nickm> Alternatively, I can just assign stuff to people in a couple of days. :)
17:07:04 <dgoulet> I can surely take a couple there
17:07:26 <nickm> thanks dgoulet !
17:07:36 <dgoulet> I have a good grasp on #26300 (at least that is that)
17:07:55 <nickm> our next thing to do:
17:08:08 <nickm> dgoulet: okay; please assign to yourself whatever you're taking
17:08:22 <nickm> next thing: code reviews!
17:08:42 <dmr> sorry to be late! :( may I get the pad URL please?
17:09:21 <nickm> looks like we're still working from last week's list, but it's been updated for this week.  People with code reviews are ahf, catalyst, isis, mikeperr1, teor, nickm
17:09:33 <nickm> everybody okay with the reviews on the review list?
17:09:41 <nickm> dmr: https://pad.riseup.net/p/dahgDhEbEhxa
17:09:47 <dmr> nickm: thanks!
17:11:09 <nickm> I'm especially eager to get all of our 0.3.4 items reviewed and merged.  If you have any of those, are you comfortable reviewing them?
17:11:39 <asn> perhaps we can mark which ones are 034?
17:11:39 <nickm> reviewews with 0.3.4 items are: catalyst, isis, mikeperry, ahf.
17:11:42 <asn> ah nice
17:12:14 <dgoulet> (datapoint: ahf is flying to SFO right now or landed there or sth)
17:12:19 <nickm> ah!
17:12:20 <nickm> ok
17:12:28 <nickm> I know isis and catalyst are here t
17:12:29 <dgoulet> (all hands Mozilla thingy)
17:12:29 <nickm> hough
17:12:36 <asn> perhaps i can take his 034 ticket?
17:12:43 <asn> and give him my 035 ticket
17:12:57 <nickm> asn if you want to , sure! He has two: #26272 and #26283. Both are simple
17:13:06 <asn> ok ill get both
17:13:55 <nickm> This week's rotations are: isis on ticket triage, mikeperr1 as community guide, nickm on coverity *, asn on CI.
17:14:16 <dgoulet> asn: we'll have to settle for #24977 tbh... else we push it to 035 but I would like to resolve it :S
17:14:24 <catalyst> nickm: isn't isis also at all hands?
17:14:32 <asn> dgoulet: yeah i added a discussion item about this
17:14:48 <nickm> * I'm going to try to do the thing we said should replace the coverity rotation, and try to schedule some proposal items
17:15:01 <nickm> catalyst: they said "o/" at the start of the meeting
17:15:23 <isis> i am at the all hands, yes
17:15:28 <isis> it starts tonight
17:15:36 <nickm> ok! Will you have time for ticket reviews etc ?
17:15:45 <nickm> and doing ticket triage this week?
17:16:05 <isis> i think so! there's some slots in the days where there's no point in me going to any session
17:16:24 <nickm> ok!  Let me know if the hallway track gets overwhelming
17:17:38 <isis> ok will do!
17:17:46 <nickm> catalyst: are you okay with reviewing the rust stuff you're listed on?
17:18:36 <nickm> next up is general discussion!
17:18:37 <catalyst> nickm: yeah, mostly need to get cross-compiling figured out
17:18:52 <nickm> ok!  If you get blocked on anything, just grab me or a rust person
17:19:02 <catalyst> if anyone's aroung this week to help answer questions about cross compilation, i would appreciate it
17:19:17 <nickm> isis, komlo: ^
17:19:22 <isis> cross compiling to mac and/or windows?
17:20:29 <catalyst> looks like i'm reviewing both (though they're the same patch?)
17:20:47 <nickm> First topic is that we're hoping to repurpose the patch party time to meet its actual applied use, which is a meet-up time for people in time zones where it's convenient.  This will still be our only weekly formal meeting.
17:21:07 <nickm> Any thoughts/objections there?  Should we just declare it or think a little more first?
17:21:45 <nickm> Second topic is related: We currently have no regular meetup time that's convenient for Europe and Australia.  Would the europeans and Teor like to pick one?
17:21:59 <nickm> That way everybody would have a time when they will (pairwise) be around.
17:22:26 <asn> that would be a third meeting, right?
17:22:31 <nickm> ahf, asn, teor: you would be the logical people to pick such a time, I think.
17:22:45 <asn> not this one, not the patch party, the "australoeuropean" one
17:22:50 <nickm> Yup
17:23:00 <asn> ok
17:23:08 <nickm> Probably 0700 UTC some day.
17:23:25 <nickm> asn: Would you like to take lead on seeing if ahf/teor/you would like this, and organizing it if so?
17:23:36 <asn> ok i can do that
17:23:40 <nickm> s/organizing/picking a time/
17:23:44 <nickm> awesome! thank you!
17:24:00 <asn> that's because teor is starting officially in july right?
17:24:03 <nickm> let's see. I mentioned replacing the coverity rotation with a proposal-advancing one
17:24:06 <nickm> asn: yea
17:24:11 <asn> ok
17:24:15 <asn> like 1st of july?
17:24:24 <nickm> I think they said 3rd of july
17:24:26 <asn> ok
17:25:20 <nickm> Next discussion thing: please see if you took any notes from seattle that aren't online yet, or which are online but don't have tickets opened for any actions we mean to take on them.
17:25:45 <nickm> If so, send a note to network-team ml, and I'll add tickets and/or a wiki page?
17:26:07 <nickm> ahf took a bunch of notes, so mentioning him here so he sees this
17:26:41 <dgoulet> ack
17:26:55 <nickm> Last discussion topic of mine on the discussion list: I think we should have a step each week at our meeting when we talk about tickets in 034-proposed or 035-proposed or whatever, and either triage them in or out.
17:27:09 <nickm> Any objections? Anybody got a great idea for a procedure for that?
17:27:41 <dgoulet> ah yes!
17:28:14 <nickm> (yes we should or yes you have an idea? :) )
17:28:15 <dgoulet> we list them, we vote if we should put it in or not where some may require discussions, success
17:28:22 <dgoulet> yes we should :)
17:28:41 <nickm> ok
17:29:00 <nickm> everybody remember to use the keywords then, and we'll try doing this next week
17:29:28 <nickm> komlo mentions two rust build tickets that need review and testing and action.
17:29:48 <nickm> I should take on #25386
17:30:58 <nickm> and it looks like catalyst is reviewer on #25895 -- so I think we have komlo's questions sorted?
17:31:16 <nickm> asn, dgoulet: want to talk about #24977 immediately after this meeting?
17:31:25 <dgoulet> sure
17:31:32 <asn> ok!
17:33:22 <nickm> dmr: want to raise your questions now?
17:33:40 <dmr> sure :)
17:33:41 <nickm> everybody ese: make sure you're reading other people's updates too
17:34:25 <dmr> I'll start with the meeting-notes follow-up; I glanced over the Seattle meeting notes and - being a bit external - might have a few pieces of valuable input
17:34:30 <dmr> summary is in the pad
17:35:16 <dmr> for CI, there was a mention of testing on Android; I just wanted to bring up that there are Android "device farms" (not sure what the industry term is) available for testing on real devices
17:35:48 <dmr> I've heard that the Android fragmentation means that some common devices out there don't function the way you'd expect, so it can be important to test on a variety of devices
17:36:16 <dmr> (I don't know much more beyond the existence of the farms-as-a-service and that fragmentation means testing headaches)
17:37:21 <dmr> I also saw notes of doing macOS CI, and wanted to mention the ability to run macOS within KVM, if on actual Mac hardware
17:37:59 <dmr> other places I've talked to who do macOS CI actually outsource that to CI-as-a-service places, so maybe Travis does support it (I'd be surprised if not)
17:38:45 <nickm> we have it set up in our travis CI file -- we just turned it off because it was super slow
17:38:54 <dmr> ahh, thanks
17:38:57 <nickm> We've heard they got faster, though: somebody should test that.
17:39:13 <nickm> (see #24629)
17:39:16 <dmr> nickm: sorry, for the question I listed as "for catalyst" in the pad, it was in regard to "Taylor mentions different concerns contributors might have to global source tree changes: downstream projects might have patches that we will break." - so I meant who is downstream _with patches_ that might break for code refactoring
17:40:00 <dmr> do we envision all of those you listed as having (or possibly having) such patches?
17:40:14 <dmr> all/any of those (idk, failing at English)
17:40:20 <nickm> yeah -- I don't know which of them have patches. I know most of them are very good at upstreaming.
17:40:47 <dmr> gotcha, thanks for clarifying :)
17:40:50 <nickm> I'll make a note to ask when I next send out a release announcement to the packagers
17:41:51 <dmr> ok, so just 2 more things from me
17:42:16 <dmr> 1) the LTS page had a question "Does people actually get our new stables? Via TorBrowser? Via Debian? Via our own Debian package mirror?"
17:42:54 <dmr> I had a friend who was running Debian stable using Debian's repos only, who reported that Tor became out of date
17:43:09 <dmr> (this was for running a relay)
17:43:33 <nickm> out of date as in "not the latest stable" or as in "not supported at all" ?
17:43:39 <dmr> they noticed it and switched to the TPO repo, but it does seem that at least for some time, the Debian repo did not get updated
17:43:49 <nickm> the former is expected, the second isn't
17:44:39 <dmr> I believe the "not the latest stable". We looked at the changelog and it showed an update by someone other weasel, seemingly delayed.
17:45:02 <dmr> sorry not having all the details ready...
17:45:08 <nickm> np
17:45:41 <Samdney> (one example for "device farms" for android (and ios) testing is googles firebase: https://firebase.google.com/docs/test-lab/, there also exists some other test lab from google, too (can't) find it at the moment, amazon also has someting like that :)
17:45:43 <nickm> any more discussions for this week? Or is our meeting done?
17:45:55 <dmr> oops, sorry, last thing
17:45:58 <catalyst> dmr: if nobody else gets to it first, i've navigated the Debian package tracker before and might be able to help with that
17:46:21 <dmr> 2) #26228 would like to move this forward; not sure how
17:47:00 <nickm> I think the situation for #26228 is that there are different areguments for doing it in different ways.  I see two ways forward
17:47:08 <dmr> right now I'm planning pretty lenient implementation in stem: set padding to ZERO bytes, and ignore such padding
17:47:10 <nickm> 1: just document what Tor does now
17:47:34 <nickm> 2: write a proposal to do something else
17:47:50 <nickm> By "ignore such padding" do you mean only if it's zero, or do you mean always ignore?
17:47:57 <nickm> I lean towards "always ignore padding"
17:48:05 <dmr> (i.e. following nickm's "the [padding] bytes SHOULD be zero, and that implementations MUST ignore them" wording)
17:49:50 <nickm> I think that's our current behavior
17:49:52 <dmr> hopefully I said that clearly. stem will pack cells with padding of ZERO bytes (following the SHOULD) and unpack cells without any validation of the padding (following the MUST ignore)
17:50:49 <dmr> ok, as I understand it: tor-spec aims to document current behavior
17:50:57 <dmr> so the "1:" you mentioned
17:50:58 <nickm> right
17:51:20 <nickm> I've said so in the ticket, in case that helps
17:51:26 <nickm> all for this week?
17:51:43 <dmr> nickm: excellent! thanks!
17:51:46 <dmr> all from me :)
17:51:48 <nickm> Any more for this week?
17:52:27 <nickm> Hearing none...
17:52:33 <nickm> Thanks, everybody!
17:52:35 <nickm> #endmeeting