18:01:42 <ahf> #startmeeting sponsor8 network team meeting
18:01:42 <MeetBot> Meeting started Thu Sep 14 18:01:42 2017 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:42 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:48 <isabela> tx
18:01:49 <ahf> cool!
18:02:09 <ahf> isabela: do you want to start with #1?
18:02:12 <isabela> alright, maybe we talk about the montly work planned by activity per activity
18:02:27 <isabela> so if you look at the storm pad
18:02:33 <isabela> the first one is 02.3
18:02:49 <isabela> let me give you some context of how this sponsor work first
18:02:51 <isabela> :) maybe that helps
18:03:02 <ahf> :-)
18:03:09 <isabela> we write a report every quarter about the progress we have made
18:03:37 <isabela> these 'indicators' are to measure our project impact
18:03:52 <isabela> we have to provide them when we are writing hte proposal and report on them on a quarterly basis as well
18:04:25 <isabela> our first report would count for august, september, october and is due at the end of november
18:04:35 <isabela> so far good?
18:04:39 <ahf> yep
18:04:49 <isabela> alright so now lets see activity 02.3
18:04:56 <nickm> query: These indicators are all things we can check now?
18:04:57 <isabela> i marked some stuff in blue which i can help with
18:05:16 <isabela> nickm: depends
18:05:32 <nickm> ahf: I believe you've started some of these items, but I don't know progress too well
18:05:38 <isabela> some we will be reporting what we have now to build a baseline for the time we will be measuring the work we are doing in this project
18:05:46 <ahf> yes!  that was sort of what i wanted to have this meeting for
18:06:10 <isabela> some we will report just a count of stuff we did, so we h ave to do it to report
18:06:30 <ahf> i've spend a lot of time on getting to understand the android system, "being able to build things myself", getting orbot up and running there where i compile it myself, started figuring out how we measure device information on the device
18:06:59 <isabela> nice
18:07:14 <nickm> cool
18:07:19 <ahf> i've started diving into nick's event emitting information that he wrote in medio august to me this week and thus wanted to have this meeting as well
18:08:14 <ahf> i feel a bit that i'd like some way to report how we progress - with sponsor 4 i had a lot of pair running with nick, but with this so far i've mostly been doing it on my own, so i wanted to figure out how we do reporting, to get things split into tasks (like we had with sponsor 4), etc.
18:08:26 <nickm> (if it's not suitable, we can adapt)
18:08:28 <ahf> how we structure it such that other people have feeling how things are going (and can reproduce it)
18:09:07 <isabela> 1. all tickets should have sponsor8 on it :)
18:09:31 <ahf> yep
18:10:11 <isabela> also, how folks does on meeting pad 'sponsor8' indicating that is about it, helps too
18:10:27 <isabela> but i guess before all that what we need is to define 'what we are doing this quarter'
18:10:43 <isabela> and list these tasks, i know you started some already, so we can use this meeting to add whatever is missing
18:10:53 <isabela> and do another quarter plan next quarter and go like that?
18:11:03 <ahf> network team meeting on mondays?
18:11:20 <isabela> ?
18:11:25 <isabela> i dont understand
18:11:30 <ahf> 20:10:49 <+     isabela> also, how folks does on meeting pad 'sponsor8' indicating that is about it, helps too <- is for the network team meetings?
18:11:38 <isabela> yes
18:11:41 <ahf> cool
18:12:44 <isabela> i would like to help with the survey - creating - sending to ppl - giving you the answeres
18:12:56 <isabela> i would need some help with the questions of course, what we would like to ask
18:13:00 <ahf> yes, the points right now in blue is something i haven't looked at at all :/
18:13:07 <isabela> i can also make a summary of what is at the play store now
18:13:08 <ahf> it seems a bit i've jumped directly to month #2
18:13:14 <isabela> that matters for this activity
18:13:15 <ahf> yes, that would be very nice
18:13:22 <isabela> ahf: is fine
18:13:32 <nickm> other than me and ahf, who else is network-team on sponsor8 ?
18:13:34 <isabela> ahf: work can shift from months to months, is a quarterly report anw
18:13:49 <isabela> catalyst is  working on the erorr reports
18:13:55 <isabela> *error
18:14:01 <ahf> isabela: yep, that is very good
18:14:10 <isabela> i am not sure if the controller too
18:14:12 <nickm> error reports ==  O2.5 ?
18:14:20 <isabela> yes
18:14:59 <nickm> ok, sorry . keep going? :)
18:15:03 <isabela> hehe
18:15:08 <isabela> alright
18:15:22 <isabela> ahf: looks like you are doing 02.3 then
18:15:41 <isabela> do you want to work off meeting on the survey questions? i can share a pad at the network team list later and others can help too
18:15:50 <nickm> (I think I will be putting time into both O2.3 and O2.5, fwiw)
18:16:09 <isabela> also, do you have any questions on what to do next (and next i mean till end of october)
18:16:19 <isabela> nickm: cool then that goes to you too :)
18:16:43 <isabela> also,
18:16:43 <nickm> sure!  I think I'm less great at survey stuff than others, but I'll look if you think it will help
18:16:46 <nickm> off-meeting is fine
18:16:54 <isabela> my other question for this activity is the baseline for the indicator we said we will report
18:16:59 <ahf> i'd like to be part of the survey questions work
18:17:02 <isabela> let me mark with green
18:17:33 <isabela> like we have to measure a fixed-size download request
18:17:45 <nickm> does progress on other stuff count, besides indicator stuff?
18:17:54 <isabela> yes
18:18:00 <isabela> we will report progress and indicator
18:18:00 <nickm> because we're promising stability improvement too, and memory usage improvement, and other stuff
18:18:11 <isabela> yes
18:18:11 <catalyst> the download speed metric is as observed by our existing infrastructure, or by the Android client on typical wireless connections?
18:18:27 <nickm> and O2.3.2 looks like it's only speed
18:18:41 <isabela> i always add an extra sheet with goodies we have accomplished when they are not marked as indicators
18:18:46 <isabela> catalyst: i dont think that exist yet
18:19:06 <isabela> nickm: is ok, if we have more metrics i can add to the report too
18:19:36 <isabela> so, yeah I am looking to see if someone can set this up and how one will be checking this measurements or how i can do that
18:19:41 <isabela> to be able to report to them
18:23:08 * ahf is reading it
18:23:16 <isabela> the green part
18:23:46 <ahf> hm, yes, so that has to be automated somehow and just run
18:24:19 <isabela> if there is an easy way to do it from an android device we could have a set group of people from our target countries, downloading the same package every quarter and giving  us their numbers
18:24:22 <nickm> and ideally, automated on android.
18:24:30 <nickm> from a target country.
18:24:44 <ahf> yes :o
18:24:45 <isabela> like a .onion url
18:24:54 <isabela> is easy to find ppl from there to do it once a month
18:24:57 <isabela> or smoething
18:25:00 <isabela> *something
18:25:32 <ahf> could we make a tiny android app where people press 'download' and it fetches a ~10/50/100MB file and reports it to us somehow?
18:25:35 <isabela> a .onion url that when they open it downloads the fixed-size file and display the time in the screen
18:25:51 <ahf> or can the people be ourself or?
18:26:02 <isabela> the person running will email us the number displayed
18:26:08 <isabela> it can be
18:26:13 <isabela> but we are not in those countries
18:26:20 <isabela> anw idk what is the best here :)
18:26:23 <isabela> just throwing ideas
18:26:36 <isabela> it can be something we ask them to run and it will just send us the info somehow
18:27:10 <nickm> this metric seems like a less-than-great way to measure the overhead/stability/app-size stuff
18:27:27 <ahf> i think it has to be easy if it not ourself - a simple variant could be to have an onion URL where people fetches a 10MB file from? it just seems very flaky to me to do this
18:27:46 <ahf> a slow circuit on that day would make it go up/down
18:27:50 <nickm> is there no metric "what is the app size; how long does it take to start and bootstrap" / "what is the cpu usage" / "how much does it crash"?
18:27:58 <catalyst> also if users in our target countries are going to run this measurement we need to figure out how to protect their privacy
18:28:14 <isabela> catalyst: yes
18:29:02 <isabela> nickm: we can report the other indicators too
18:29:12 <isabela> nickm: is fine to add those
18:29:42 <catalyst> "how much does it crash" might be included in O2.4.1
18:29:43 <isabela> if we feel we should change this one i can work on it with them too
18:29:45 <nickm> the" app size; startup time; cpu usage " ones should be easy to get
18:30:11 <isabela> by app size you mean what
18:30:24 <isabela> how much tor will add to your app size
18:30:30 <isabela> if you have it embed
18:30:34 <nickm> Total binary size at rest; total ram usage when running
18:30:50 <nickm> including libraries that we make the user download and keep
18:31:23 <isabela> ok
18:32:18 <ahf> one of our goals is to make the tor "package" for android smaller as well?
18:33:13 <nickm> if I'm reading the activity descritpion right, I think do
18:33:17 <nickm> *so
18:33:29 <isabela> yes
18:33:51 <isabela> alright
18:34:19 <isabela> i think we could still report on the donwload speed
18:34:30 <nickm> yes
18:34:44 <nickm> that's the hardest one to improve, though :)
18:34:54 <isabela> yes
18:34:58 <nickm> we'll see the biggest improvements on the worst hardware on the worst networks
18:35:08 <isabela> hopefully
18:35:09 <nickm> since that's where we've spent the least optimizing time so far
18:35:15 <nickm> right, hopefully :)
18:35:30 <isabela> so i think it would be worth to have a .onion url that we can ask one person on each target country to do it
18:35:40 <isabela> and run this measurment for us
18:36:07 <isabela> it can display the results right there at the url and they just need to copy and send to us
18:36:12 <isabela> it can send to use automatially
18:37:31 <ahf> i can set an onion up on some VM, that is no problem
18:37:49 <ahf> i assume we want it to be a single hop to make the results just a tiny bit more stable?
18:37:58 <nickm> +1 there
18:38:11 <nickm> some improvement will be due to HS performance improvements, but that's likely ok
18:38:31 <ahf> should it just be a "big" file or do we want some content in it? or should it be the application (.apk) itself?
18:38:41 <catalyst> how do we know what country the user is in? do they self-report when running the tool?
18:39:00 <nickm> ahf: I don't know; what do you thinK?
18:39:09 <isabela> ahf: no big file
18:39:13 <isabela> i mean not too big
18:39:19 <isabela> we dont want to eat the ppl data plan
18:39:27 <isabela> that costs $$ over there
18:39:45 <isabela> catalyst: we will contact people from our target countries from this project
18:39:56 <isabela> catalyst: people we know from the community
18:40:25 <isabela> this url wont be shared publicly - we will share with folks there and they will tell us the numbers they get
18:40:31 <catalyst> so we're not breaking it down by country? that's probably better privacy-wise
18:40:37 <ahf> 1 MB? i mean, maybe we can just have a set of files there for different people? 1MB, 2MB, 5MB, 10MB, 100MB ? i don't know much about how the data plan structures are in our target countries
18:40:56 <isabela> catalyst: we need a person from Kenya, Nigeria, Colombia, and India
18:41:08 <isabela> those are our target countries for this project
18:41:17 <ahf> cool
18:41:43 <isabela> ahf: i would say a fixed file size for all countries, 2MB should be ok i think
18:41:47 <isabela> i would double check that
18:41:58 <isabela> and i also plan on help find the people etc
18:41:59 <isabela> :)
18:42:02 <ahf> ok, i will set a service up with that with a single hop onion
18:42:03 <isabela> i will talk with the community team
18:42:24 <ahf> #action ahf sets up single hop onion service with 2 MB file for testing
18:43:42 <isabela> ok
18:43:52 <isabela> i added a few at the pad, including this one
18:44:04 <isabela> maybe we can move on to the next activity?
18:44:16 <isabela> 02.4
18:44:43 <ahf> yep
18:44:50 <nickm> Question: Is "reduce battery usage" under this one, or under O2.3?
18:45:02 <isabela> it also has a survey :) so i hope we can combine all the surveys into a one thing
18:45:14 <isabela> 02.3
18:45:28 <ahf> combinging them sounds like a good plan
18:45:40 <nickm> okay.  then we should make sure that our battery usage, wakeup/sleep stuff is also measured in O2.3
18:45:56 <nickm> from what I hear, battery usage is maybe our biggest problem atm
18:46:00 <ahf> isabela: one thing i'd really like to know from the survey is what kind of devices people are using.  i have got a really cheap android device that i use as my "low end" device and a fancy one for my "high end" testing
18:46:04 <ahf> nickm: +1
18:46:36 <ahf> during the meeting nick and i had in august we also put our order of looking into things as battery first, then network, then on device storage
18:46:42 <catalyst> would be good to know if battery usage is dominated by CPU or radio transmission
18:46:43 <isabela> nickm: ok so, app size, startup time, cpu usage, battery usage?
18:46:59 <nickm> yeah; and possibly "unwanted wakeups"
18:47:04 <nickm> catalyst: +1
18:47:18 <nickm> catalyst: my sense is that our biggest battery problem is not paying attention when we're told to sleep
18:47:23 <catalyst> nickm: we have _lots_ of one-second periodic timer events right now, it looks like
18:47:31 <nickm> catalyst: but I don't think we have measurements to back that up
18:48:04 <isabela> nickm: you saying the battery problems might be better fixed with the controllers work?
18:48:05 <catalyst> ahf: could you summarize what tools you know of for profiling battery usage details on Android?
18:48:09 <isabela> ops
18:48:16 <isabela> nickm: sorry you are right
18:48:23 <isabela> nickm: battery use is 02.4 not 02.3
18:48:32 <isabela> "to better control bandwidth and battery use."
18:48:40 <isabela> is right there at 02.4 title :(
18:49:00 <nickm> isabela: I'm thinking that we might actually fix the battery problems without much controller work, if the answer to the question is less "obey the application" and more "don't be stupid"
18:49:11 <ahf> catalyst: yep!  i use a tool from 'adb' right now called 'dumpsys'
18:49:11 <nickm> so I was wondering what category it came under
18:49:28 <ahf> https://developer.android.com/studio/profile/battery-historian.html + https://developer.android.com/training/monitoring-device-state/index.html is the info sites i've in my notes
18:49:41 <nickm> i'm cool either way so long as we're measuring battery and improving it
18:49:49 <isabela> yes
18:50:42 <isabela> i will keep this indicator
18:50:49 <ahf> it's the events i started diving into this week: figuring out if i can see a noticable result if i can disable some events as a "dummy test" and ensure that we work nicely with android's own "doze" events.
18:51:01 <isabela> i think if one or another or both impacts everyone will be happy :)
18:51:37 <nickm> neat
18:51:44 <isabela> so we need to add baselines for all these indicators
18:52:09 <isabela> app size (what is now), startup time (what is now), cpu usage (what is now)
18:52:16 <isabela> battery usage (waht is now)
18:52:51 <ahf> i guess for 'startup time' we need one where we look "just" on "little t tor" and one where we look at orfox itself? or should we only focus on the former?
18:53:13 <isabela> for now little t tor
18:53:31 <isabela> i will report it separated
18:53:41 <isabela> because by the time orfox is booting with tor launcher on it
18:53:43 <ahf> cool
18:53:46 <ahf> yep
18:53:47 <isabela> it will be long into the project :)
18:54:37 <isabela> maybe we can answer the baseline question off meeting?
18:54:48 <isabela> and we move back to 02.4 :)
18:55:04 <ahf> so find a baseline for these metrics with current little-t-tor on device via orbot?
18:56:05 <isabela> hmm i think so, i think this is actually the only way we an measure it on device
18:56:17 <isabela> *can
18:57:04 <ahf> agreed
18:57:18 <ahf> then we run into one of the things i've mentioned a bit with that we have no baseline device right now
18:57:30 <ahf> so i can do it on a "small" moto-e and a nexus 5x
18:57:39 <isabela> i have one
18:57:48 <ahf> then we have to reproduce it using similar devices
18:58:04 <isabela> true
18:59:33 <isabela> ahf: i would suggest the following - lets figure out how we collect those measurements
18:59:36 <isabela> first
18:59:40 <isabela> than from where
18:59:41 <ahf> yes!
18:59:45 <ahf> yep
19:00:03 <isabela> if we are doing with orbot, lets do it once we can use our own devices and when its working
19:00:22 <isabela> we can reproduce it with other devices and maybe the folks doing .onion url download test could do this one too
19:00:25 <isabela> who knows!
19:00:27 <isabela> :)
19:00:29 <ahf> yep, agreed
19:01:00 <isabela> so you were digging into it already? do you want to pick that?
19:01:08 <ahf> yes
19:01:15 <isabela> cool
19:01:26 <isabela> i have android too so if you need anyone testing weird sstuff for you :)
19:01:52 <ahf> yep, i think most people in our team have android devices - might become useful :-)
19:02:03 <isabela> i guess for 02.4 main part is to find developers requirements
19:02:27 <isabela> at least for this quarter
19:02:45 <ahf> yep. i'm a bit blank on that one
19:02:50 <isabela> and start with design proposals for it
19:03:11 <isabela> hmm
19:03:25 <isabela> i think we can take it offline and do via email lisst as part of the other survey conversation
19:03:40 <isabela> does anyone knows of any requirements
19:03:53 <isabela> like folks that might have mentioned needs at tor-dev
19:03:57 <isabela> or f2f or something
19:04:05 <nickm> not for controller stuff wrt battery
19:04:13 <nickm> i think everybody just wants "battery usage should be less"
19:04:24 <nickm> I think that the controller part will come into play if we find out that there are any tradeoffs
19:04:26 <isabela> ok but just in general
19:04:27 <nickm> oh!
19:04:29 <nickm> i thought of something...
19:04:30 <isabela> for the controller interface
19:04:56 <isabela> nickm: yes?
19:04:57 <isabela> :)
19:04:58 <nickm> see #23289
19:05:12 <nickm> that's something where there might be a tradeoff involved
19:05:15 <ahf> oh, sorry, i was thinking of 2.4.1
19:05:30 <nickm> ah
19:05:32 <isabela> we cant do hs stuff for this sponsor
19:05:47 <nickm> well, hang on a sec and let me know if you agree with this:
19:05:49 <ahf> 2.4 was my initial plan to try out if the doze functionality can be integrated with us
19:05:57 <nickm> we aren't doing to do hs stuff for this sponsor.
19:06:00 <ahf> so we can make things "sleep" in tor when the OS tells us to
19:06:39 <nickm> _but_ if we do faster HS wakeup, then it might be a tradeoff with battery life, which gives us a reason to do battery stuff with controller support
19:06:51 <nickm> so the application can say what kind of wakeup tradeoff they want
19:08:24 <isabela> another part of the controller stuff is about managing connections and circuits
19:08:29 <nickm> yeah
19:08:35 <isabela> or is that related to what you are saying
19:08:43 <nickm> maybe? we can find out.
19:08:46 <isabela> :)
19:08:50 <isabela> hehe sounds good
19:09:02 <nickm> #23289 is an example of "something an app dev wants", so i brought it up.  we can probably identify non-hs-specific parts
19:09:24 <isabela> can i ask something? maybe we can use a keyword for the activity the task is related
19:09:32 <isabela> besides just using the sponsor8 component
19:09:38 <ahf> yes, please
19:09:40 <isabela> A02.4
19:09:48 <ahf> i think david and george is doing quite well with that for their hs project
19:10:26 <ahf> hm, so use the indicator name for it? should work
19:10:43 <isabela> so we would have A02.3, A02.4 and A02.5?
19:10:51 <ahf> yep
19:11:03 <isabela> nickm catalyst ^^ ?
19:11:08 <nickm> i'd be more comfortable with memorable names, if that wouldn't make it too hard
19:11:16 <isabela> hehe
19:11:17 <isabela> sure
19:11:29 <isabela> lets give nicknames to these activities :)
19:11:50 <nickm> like s8-perf, s8-battery, s8-control, s8-bootstrap, s8-errors?
19:11:52 <ahf> 23 = sponsor8-netthroughput, 24 = sponsor8-battery, 25 = sponsor8-error ?
19:12:00 <ahf> yeep, shorter :-P
19:12:04 <isabela> heheh
19:12:22 <nickm> we're going to have to type these a million times :)
19:12:22 <isabela> what is perf?
19:12:28 <nickm> perf(ormance)
19:12:32 <isabela> ahh
19:12:33 <isabela> :)
19:12:51 <isabela> ok
19:13:02 <isabela> i like -> s8-perf, s8-battery, s8-control, s8-bootstrap, s8-errors
19:13:04 <isabela> better
19:13:11 <isabela> sorry ahf :P
19:13:38 <isabela> also this way we can have s8-battery for 02.3 and 02.4 depending on what we are doing
19:13:41 <isabela> :)
19:14:05 <ahf> yep, i like the shorter ones much better as well
19:14:40 <catalyst> yeah i like the shorter names (these will be trac keywords?)
19:14:46 <ahf> yep
19:15:05 <isabela> yep
19:15:16 <isabela> alright
19:15:20 <isabela> almost there people!
19:15:23 <isabela> sorry is a long meeting
19:15:48 <ahf> :-)
19:16:09 <isabela> i would say - go wild and tag things now that we have those and you think a task would be a good fit for the work we need to do here
19:16:18 <isabela> last one!
19:16:22 <isabela> 02.5
19:16:24 <isabela> ahh
19:16:30 <isabela> btw - indicator for controller thing
19:17:59 <isabela> i think to know of 'reproducible failure'
19:18:06 <isabela> will be the hard part
19:18:27 <isabela> or maybe we will learn of those via the survey
19:18:31 <catalyst> i know one thing that's quite reproducible right now is the clock skew hangs
19:18:36 <isabela> aha!
19:18:51 <isabela> we should keep countof those, and of course, if we fix those
19:19:04 <catalyst> _where_ it hangs depends on the direction of the skew and whethere there's a cached consensus
19:19:10 <nickm> many pt failure cases are easy to replicate
19:19:43 <isabela> ok
19:20:28 <isabela> can i assume i will be able to know what 'failure' a s8-control ticket is fixing?
19:20:37 <isabela> if so, i can count these and report
19:21:02 <nickm> s8-error or s8-bootstrap, you mean?
19:21:16 <isabela> this is for the controller activity
19:21:17 <nickm> also i think our goal is less to "fix" and more to "report accurately"
19:21:19 <nickm> ah
19:21:40 <nickm> O2.5 though?
19:21:46 <nickm> or still on O2.4 ?
19:21:48 <catalyst> reporting an error is better than hanging
19:22:01 <isabela> ok
19:22:07 <isabela> 02.4 indicator unit is : Unit: Application failuresType: Output
19:22:27 <catalyst> O2.5 would seem to be making existing error reporting more useful?
19:22:31 <nickm> I wonder if we will have a complete list of errors to resolve/report when we start, or whether that will grow as we make work
19:22:36 <isabela> i guess i will count all new controller we write?
19:23:12 <nickm> for o2.5 i think we're planning not on writing new controllers, but on reporting more errors/problems under the system we have?
19:23:18 <isabela> catalyst: yes
19:23:29 <isabela> catalyst: and the indicator of that is Unit: Error casesType: Output
19:23:41 <isabela> so is very related to the progress bar you are looking at
19:23:55 <isabela> and i guess we will report all the error cases we cocver
19:23:57 <isabela> cover
19:24:06 <catalyst> i think for core tor we can add parameters to the errors we do report, but going into details of recommended solution might get too verbose for a control protocol
19:24:07 <isabela> nickm: is ok if doesnt grow
19:24:26 <isabela> nickm: we just need to make sure we are pro-active in collecting feedback/needs
19:24:31 <nickm> ok
19:24:52 <isabela> nickm: so we can say, no one is reporting anything to fix anymore, looks like we did it!
19:25:09 <isabela> but we cant say that without saying how we know no one is
19:25:13 <isabela> anw
19:27:06 <isabela> catalyst: maybe the case is that the error msg is not clear
19:27:31 <isabela> if its better reported there might be no need for 'recommendation for fix'
19:28:39 <catalyst> related is having bootstrap phase names accurately reflect what tor is doing so it's more obvious what things are hanging or taking a long time (right now many of them are lies)
19:28:59 <isabela> hehe
19:29:00 <isabela> true
19:29:02 <ahf> what does it mean that we need to "*confirm* network error reporting" for month #3 ?
19:29:09 <isabela> i think we might have more insights with the surveys too
19:29:46 <isabela> hmm
19:30:19 <isabela> i guess some type of test
19:30:44 <isabela> sorry i was not necessary the one who wrote this :) but i am the one that needs to help make sense of it
19:30:54 <isabela> hehe
19:31:00 <ahf> yep :-)
19:31:16 <isabela> i dont get the per release
19:31:33 <ahf> yep
19:31:52 <catalyst> i'm inserting line breaks so i can read this more easily :)
19:32:00 <isabela> nice
19:32:02 <isabela> hehe
19:35:04 <nickm> (what's left to do for today? I'm nearing the end of my meeting-brain)
19:35:31 <isabela> i feel ya
19:35:41 <isabela> i think we actually did a good chunk
19:35:56 <isabela> and should be good
19:36:04 <isabela> i will follow up via email on this survey stuff
19:36:13 <ahf> cool. i will continue with the battery work, but will fix the actions for tomorrow. when do we catch up on the survey stuff?
19:36:13 <isabela> ppl should tag tickets!
19:36:34 <ahf> and is someone taking "ownership" of the error reporting tasks for now? or do we expect those to happen later in this quarter?
19:36:39 <isabela> i can get the ball rolling today or latest tomorrow via email
19:36:47 <ahf> cool
19:37:03 <isabela> catalyst: do you want to look at the error thing?
19:37:14 <isabela> catalyst: also, if you want to look at other stuff too
19:37:15 <isabela> let us know!
19:37:23 <catalyst> i kind of already have been looking at error reporting
19:37:30 <isabela> yep :)
19:37:55 <catalyst> this clock skew hang stuff seems to be a really big problem
19:38:28 <isabela> is that something the controller thing can fix?
19:39:35 <catalyst> it's something only core tor can easily fix -- by actually reporting errors rather than sitting there doing nothing (or waiting on excessively long timeouts)
19:40:37 <isabela> if you want to pick that up, go for it, just tag the ticket with the keyword
19:40:38 <catalyst> we can improve error reporting (mostly parameterizing?) so controllers have an easier time describing possible solutions to the user
19:41:05 <isabela> we can start fixing things we already know, the survey will help add more stuff - specially what we dont know
19:42:20 <catalyst> are we noting trac keywords on the pad alongside the activities?
19:42:40 <isabela> i just listed them atthe top
19:42:41 <ahf> good idea
19:42:48 <isabela> but i can organize it by activity
19:44:02 <isabela> i might have done something wrong
19:44:03 <ahf> cool
19:44:06 <isabela> :) please review
19:44:07 <isabela> hehe
19:44:22 <catalyst> ok thanks!
19:44:36 <isabela> ok
19:44:43 <isabela> anything else?
19:44:48 <ahf> looks good
19:44:53 <ahf> i don't have anything else
19:45:02 <ahf> you poke us about the survey tasks, isabela?
19:45:10 <isabela> yes sir
19:45:12 <ahf> cool!
19:45:17 <ahf> i'll end the meeting. thanks all
19:45:24 <ahf> #endmeeting