14:28:53 #startmeeting metrics team 14:28:53 Meeting started Thu Jul 12 14:28:53 2018 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:28:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:31:47 irl: you here? 14:31:53 * irl 14:32:01 great! ready to start? 14:32:05 sorry, had a phone call unexpectedly 14:32:10 ready to start 14:32:16 no worries. okay, great! 14:32:22 * New lookup service (karsten) 14:32:37 I saw your response on that thread. 14:32:53 it sounded like you liked the idea. 14:33:22 yes, i think it's a good idea 14:33:53 * karsten tries to find the deadline.. 14:34:20 july 31, I think. 14:34:43 do we write the proposal, or some of it, or is that someone else? 14:35:22 that's a fine question. but even if someone else does we'll have to make sure it describes what we want to do later. 14:35:44 ok 14:35:57 should we start a new pad for this idea and start writing down our ideas? 14:36:07 that sounds like a good idea 14:36:34 how's tomorrow afternoon as deadline for this part? 14:36:44 the requirements? 14:36:57 the general idea, the benefits, etc. 14:37:09 ok, sounds good 14:37:11 basically, a more comprehensive reply for isabela. 14:37:25 okay, I'll start a pad after this meeting. 14:37:32 cool 14:37:58 * Roadmap updates 14:38:16 should we go through the list and update progress for all items? 14:38:17 i noticed that our roadmap on the wiki was looking outdated 14:38:21 sounds good 14:38:46 yes, that's true. it's a bit outdated. though there was not much to update in june. 14:38:49 but let's do it now. 14:40:33 oh dear. this has not pasted well 14:40:44 ah, wait, I have a better plan. 14:41:34 better. 14:41:37 yay (: 14:47:39 so, anything missing? 14:48:11 any why does trac change the 19. to a 10. ... 14:48:37 i think it just does an
    with a starting number maybe 14:48:49 i think that is all 14:49:09 probably. but there must be a way to work around that. I'll find out. 14:49:51 blank line between them so it's in a new group? 14:50:09 yes, maybe. 14:50:26 I'll do that after the meeting. no need for you to wait for me reading the manual. 14:50:53 okay, next one? 14:50:56 yep 14:51:00 * Onionoo release planning (karsten) 14:51:11 we have a few changes already. 14:51:28 should we put out a new release in the next days, that is, early next week? 14:51:40 and if so, is there anything that should go in that we didn't write yet? 14:52:08 #6946 is still in need of review 14:52:29 nothing else that i'm working on at the moment though 14:52:48 yes, that review is on my list. 14:53:10 okay. then let's just release what we have. 14:53:16 sounds good to me 14:53:19 (including #6946 once it's in.) 14:53:30 early next week? 14:53:45 depends how quickly you can do the review 14:54:02 but this works for me 14:54:26 I think tomorrow is too optimistic, if I also want to write something for isabela. 14:54:42 i mean, if you're too busy, then later next week is also ok 14:54:44 release includes doing the instance upgrade dance, too. 14:54:51 ah, early next week should work for me. 14:54:58 ok, let's do it then 14:55:04 alright! 14:55:13 * monorepository for all metrics code (karsten) 14:55:19 this is a more long-term idea. 14:55:29 oh no 14:55:42 I noticed that we're making the same changes to multiple repositories. 14:56:00 and in practice this means we're only doing them to some, not all of them. 14:56:25 okay, then maybe we can find a way to avoid this issue with our multiple repositories. 14:56:37 well, with the current codebase maybe it's a good idea 14:57:04 but with the new lookup service, i was starting to think about how we might change the architecture of tor metrics into a series of smaller loosely coupled services 14:57:30 yes, but that would still be possible with a monorepo. 14:58:04 we would just generate 10 different jar files for the various services. 14:58:15 ...and they wouldn't all necessarily be java services 14:58:17 of have 1 jar file and 10 different configurations to do vastly different things. 14:58:22 ah, oh. 14:58:28 (long long term idea) 14:58:36 heh. what would they be written in? 14:59:02 whatever, as long as there is a good reason for it 14:59:36 i think at the moment it is not very clear what the best interfaces are to use for metrics services, except maybe for onionoo 14:59:55 collector is best consumed with metrics-lib but in other languages you have per data format rules on filenames, etc 15:00:07 there's not really a "native" collector interface that we implement with our own tools 15:00:15 we've always just adopted the interfaces that other tools had 15:00:52 i wonder if the new bandwidth list format could be generalised to turn it into a generic interface that we could write parsers for, and then have that as the output format for the new lookup service, for example 15:01:17 then the lookup service provides a webserver to fetch those files from, similar to dir-spec's protocol 15:01:29 maybe this is a crazy idea though 15:01:45 no, it's worth thinking about how to simplify things. 15:02:14 having seperate code paths should be the "exception" not the "normal" ideally 15:03:03 well, okay. 15:03:04 but now that i think more about it, this would probably require refactoring, and that might be easiest achieved in a monorepo 15:03:20 maybe let that idea sink for a bit. 15:03:29 no need to make a decision today. 15:03:42 i will keep it in mind 15:03:55 I just observed that some changes are harder to make in all tools than they should be. 15:04:32 and please keep thinking about other long-term changes, like languages, etc. we could discuss this more in mexico. 15:04:45 ok cool 15:05:10 so far the main argument for java has been that there's simply so much code in java that changing that would keep us busy for many months without making actual progress. 15:05:39 anyway. 15:05:56 did we run out of topics? 15:06:01 i have no more topics 15:06:24 alright! looks like we have action items on the pad and in our inboxes. 15:06:57 thanks, and bye! 15:07:01 bye! 15:07:02 #endmeeting