21:00:15 #startmeeting talking about s31 and modularization 21:00:15 Meeting started Wed Mar 13 21:00:15 2019 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:00:20 thanks nickm! 21:00:27 Hi! Gaba asked me to run meetbot. 21:00:53 The idea for this meeting is to check that we are all on the same page about what needs to be done with this project as well as check if we are on track. 21:01:06 yes, meeting logs are useful for me later. thanks 21:01:19 ok. i have all things loaded. 21:01:37 There was a meeting in Brussles where it was decided what needed to be done around refactoring. 21:01:48 yeah 21:01:53 * catalyst trying to chase down #29201 title discrepancy 21:02:24 mm, yes 21:02:37 i think the ticket number is wrong 21:02:45 the card in the kanban (that came from burssles) talk about split up contro.c 21:02:49 the same ticket number 21:02:51 #29210 21:02:59 #29201 21:03:05 ack. let's fix kanban and pad 21:03:37 done 21:03:40 woo 21:03:41 oh, I see 21:03:42 thanks 21:03:51 (It would be really nice to have a board that integrated with trac. There are a lot of typos in the kanban. Which is a problem with manually re-typing stuff.) 21:03:59 omg yes 21:04:14 * nickm would benefit from a ticketing system where no ticket's id is a permutation of any other's 21:04:29 * catalyst hopes to not have to dig into Trac guts but maybe that is inevitable 21:04:33 (Hamming distance) 21:04:56 How far away you need to stand from pork while it's curing? 21:04:59 ;) 21:05:01 anyways 21:05:06 :) 21:05:11 yeah i could have been responsible for the transposition because it's something i'm particularly prone to do :-/ 21:05:20 catalyst: me too though 21:05:29 this is what we promised the sponsor: 21:05:30 1. Determine how to best refactor modules to make them more resilient, segregated, and automatically testabl 21:05:33 2. Identify which parts of the codebase are most important to refactor first. 21:05:34 Systemic issues are not anyone's fault :-) 21:05:36 3. Revise the system of interactions between modules to improve usability and maintainability. 21:05:39 4. Create and deploy plan to incorporate refactored modules. 21:05:42 5. Create documentation for how Tor modules work with one another with both old and new architecture. 21:05:47 how far of we are, is that a plan that does not work, we are on trac and everything is fine? thoughts? 21:06:48 i maybe think those "deliverables" are better thought of as guidelines about how we want to go about this rather than discrete well-defined steps or phases 21:06:49 so imo: we have 1 and 2 sort of in progress. 3 is also in progress 21:06:54 yeah 21:07:27 The deliverables were written in a time when we had a proposal and the sponsor said "um we need deliverables" so we wrote some that were sufficiently general to encompas the right thing 21:07:42 yes 21:07:46 as long as we do the important refactoring and document everything, we are set. 21:08:02 ok, so we are fine with that. 21:08:03 is the sponsor expecting us to report things as if they were discrete phases? 21:08:30 not really, they are expecting for us to report on what we are doing and plans. 21:08:56 We will have to report on 2. (need to check exactly when but not soon) 21:09:31 the plan is engineered to make sure we succeed. We should be fine 21:09:34 i guess we kind of already accomplished a lot of 2 in the process or making the roadmap? 21:09:41 yes 21:09:46 yes. The other question is, from what we are planning to do, is there anything missing? 21:10:14 I think that the best time to answer that is in a month or two. 21:10:26 Right now we aren't far enough into the plan to know what it is missing 21:10:28 IMO 21:10:41 some of our practices stuff isn't exactly refactoring, so we might want to reword (1) 21:11:01 or explicitly add a deliverable about improving practices? 21:11:49 Or declare that improving practices is part of making refactoring more viable and "sticky" 21:13:06 ok. In two months we should have finish all the issues we have in the backlog in the roadmap for that sponsor. I can add a reminder to check again between everybody then. 21:13:13 anyways I think we're on track; we think that "modules" and "subsystems" and "pubsub" are the right directions to move... 21:13:28 ... and we think that the "god modules" (control, config) are a good place to start 21:13:39 ok, it sounds good 21:13:50 asn, teor4: do you have any thoughts about this? 21:13:58 and that we should also look at src/core, since it's too big 21:14:09 aha 21:14:10 What about refactors that we needed to do for other sponsors? I have done a significant amount of refactoring for Sponsor V / PrivCount. 21:14:10 makes sense to me 21:14:41 Do we want to count that under 31 or V? And if we don't count it for 31, do we at least want to mention it in our 31 reports? 21:15:03 So, I don't know if it's kosher to decide whether to bill V or 31 based on 21:15:11 It seems to me that we could count under s31 as we have more resources tehre now. 21:15:12 i think 31 as being more proactive rather than reactive 21:15:15 whether we have more funding in one or the other. I think not... 21:15:22 :) 21:15:28 s31 is about refactoring 21:15:33 what should we based it on? 21:15:43 but I think that in general sponsor V is only paying for "make privcount happen" at this point, and not even all of the work we have left there 21:15:44 catalyst: i see 21:15:45 so refactoring that's needed to accomplish some V stuff maybe belongs under V 21:15:50 whereas refactoring does fit nicely under 31 21:16:29 (that is to say, if V were the only funder, given the amount of cash left in that contract, I would say "minimize refactoring, kludge it together.") 21:16:50 but they're not the only funder, so we can do the refactoring under 31, I think 21:16:51 (that would have been useful to know a bit earlier...) 21:16:52 maybe we can think about 31 as refactoring that we've needed to do for a while but has been too big to do as overhead for something else 21:17:01 I am thinking of a statement like: "our statistics code is a 'god module' and we have started refactoring it" 21:17:23 hm 21:17:33 oh, there's a bunch of existing stats stuff? 21:18:59 +1 to 31 as refactoring what needed to be done for a while /catalyst 21:19:00 catalyst: I'm not sure what you mean? 21:19:18 i hadn't realized that the stats code had become a "god module" 21:19:23 catalyst: src/feature/stats tried to grab most of it 21:19:32 it isn't a god module in the sense of calling everybody... 21:19:40 Well, it is called from many places. It doesn't call into many places. 21:19:55 but it does have the problem of everybody calling it while it is not (structurally) a dependency of everything else 21:20:25 and its design is structured so that it has to know about all the stats anything wants to record 21:20:43 so it has to know lots of data structures that "belong" to other code? 21:21:23 there's a little of that. What I meant is that if there's code that does foo, then the stats code has a foo_stats, and if there's code that does bar, then the stats code has a bar_tracker 21:21:46 teor: am I about right her? 21:21:49 *here 21:22:32 Yeah, I think we are sometimes good at reducing the data dependency, and sometimes not. But the stats code definitely contains a mishmash of calls and concepts from other modules 21:22:49 It is also not standardised, which makes it easy to write bad or divergent stats code. 21:22:50 maybe less a god module and more a frankenmodule 21:22:52 but it's trouble 21:24:24 that is all from my side about checking with you all on s31 work :) 21:24:33 anyways, I think if we notice that something needs refactoring while we're working on something else, odds are good that we will find that it is the kind of thing we want to refactor anyway 21:24:57 gaba: What do we need to do to ensure that we make good progress over the next month or so IYO? 21:25:00 yes, it would makes sense to consider to include it here for the next few months 21:25:23 nickm: if we are not missing anything from the current roadmap for next two months 21:25:35 then we are fine. We can check again in 2 months. There is plenty of work for it. 21:26:05 The are a few issues that should have started in March 21:26:14 but we are still in march :) 21:26:28 i have a question wrt roadmap and me. im done with sponsor31 roadmap items for now, but i have another big one in april. and april is when the onion services funding starts. so im not sure how thats gonna balance out 21:26:31 let's look at them. I remember one is the control.c split. catalyst and I are not yet started on that. 21:27:05 right asn, that one is with teor 21:27:10 #29224 21:27:11 i think its with nick 21:27:33 mmm, which one? 21:27:39 no its another one about hiding structures 21:27:42 i saw it before in kanban 21:27:43 let me try to find it again 21:27:52 #29209 21:28:00 nickm: yes, the ones for march are #29210 as you mentioned and #29219 and #29220 21:28:41 oh yes asn, that one is a big one 21:28:42 not sure if this meeting is the best place to figure this out, but im just mentioning it because it's gonna come up sooner or later, and gaba you are going to be away until april 21:29:08 I am lagging on my Sponsor V tasks, mainly because they are bigger than I thought (but leave and process changes didn't help) 21:29:09 catalyst: we need to coordinate on getting the control.c split-up started in a way that involves minimal blocking-on-each-other 21:29:26 teor: ack 21:29:28 yes, let's talk later with nickm and see how we can do it or redistribute it 21:29:35 asn* 21:29:39 ack 21:29:40 So I am happy if someone wants to do an initial design or draft of Sponsor 31 tasks, and then ask me to look at it 21:29:50 nickm: yeah that might be a good idea but i'd have to look more closely to see how feasible that is 21:30:14 asn: let's chat the first week of april about it. 21:30:27 gaba: ok 21:31:22 ok? 21:31:28 wrt best-practices, we mainly decided to focus on the ones we can measure, like complexity metrics 21:31:33 there are more we could do 21:31:56 reducing type visibility is nice and incremental, since we can do that one at a time 21:34:29 it makes sense 21:34:59 is everybody ok with the work for this for the next 2 months ? (other than asn that we talked later) 21:35:28 I think we have some progress here. Is there more we should figure out before we let the sleepy people sleep and the early people have breakfast and the nickm people make dinner? :) 21:35:33 s/talked/talk 21:35:44 I think we'll be fine for at least a few weeks till you're back :) 21:36:07 yes :) I just wanted to make sure we are not missing anything here but is fine 21:36:36 thanks for waking up early or staying up late! 21:37:02 ok. meeting done? I'll be around, on and off, for at least 20 min 21:37:20 thanks for meeting! 21:37:21 yep 21:37:36 peace all 21:37:39 #endmeeting