23:02:12 #startmeeting S31 september update 2019-09-11 23:02:12 Meeting started Tue Sep 10 23:02:12 2019 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:02:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 23:03:12 do we want to continue from the agenda from last weeks meeting? 23:03:23 hi! 23:03:27 https://pad.riseup.net/p/IRjuGtQkWNKZLc7qskDb 23:03:32 yes 23:03:47 some of you wrote stuff in each agenda item 23:04:02 maybe we can go through the agenda and see if anybody has something else to add 23:04:27 sounds like a good idea. looks like some of the items have been handled like #5 23:04:36 and discuss when there is discussion to be made (item 7. for sure) 23:04:59 are people ok with meeting in irc or do any of you want to do voice meeting for this? 23:05:02 blue = catalyst in this one? 23:05:11 ah, yes, looks like it 23:05:14 ahf: yeah 23:05:21 I can't do voice today, I have a sore throat 23:05:54 oki, let's keep it at irc then. would it make sense to do voice for the recurring s31 meetings? 23:06:06 let's figure out when they happen 23:06:25 ack 23:06:44 ok 23:06:45 should we begin at #2 ? 23:07:06 " 23:07:07 2.0 how can we work as a team for this project? what we need for collaboration, maybe regular specific s31 meetings?" 23:07:19 everybody agree with regular meetings then? 23:07:34 every 2 weeks seems to would be good as we have 3 more months for this project 23:07:49 Sure, let's repeat at this time, and see how we go? 23:07:58 sounds good 23:08:01 cool, so next one after this in 14 days 23:08:02 that would be okay with me. Starting weeks from today? 23:08:08 (catalyst: is that okay w you too?) 23:08:10 starting in 2 weeks from today 23:09:13 nickm: yeah alternating Tuesdays 23:00 UTC works for me 23:09:39 ack 23:09:47 cool 23:09:57 2.1 Can we do design documentation or proposals for refactors? 23:10:19 I agree with what everybody has written there 23:10:35 catalyst: you are saying that a big design document is not a good idea. how the conversation for this should go? 23:12:20 i read it as a hint that we should avoid doing very large proposals for large refactoring upfront and do it more iteratively? 23:12:33 ahf: yes 23:13:31 but, it makes sense to do teor's idea with the part in mind that if things grows too large they probably need to be split up? 23:13:32 the way i prefer to do large refactoring projects is to sketch out the broad goals, knowing they're likely going to change in the future. refine the design as more experience with implementation happens 23:13:45 nod 23:13:58 sounds good and concrete 23:14:21 and make it so that the actual implementation will be in incremental steps that get us closer to the larger goal 23:14:41 yeah 23:14:44 ok 23:15:00 teor: you ok with this? 23:15:16 like... figure out roughly what the new thing will look like. implement enough of it to start making a proof of concept moving a few small concrete things over to it... 23:15:20 Seems okay to me; for larger projects, I'd like a memorandum of the conversations so that we know what we think we agreed to, even if we also agree that our decisions are always modifiable. 23:15:21 Sounds good 23:16:00 i think my way can feel like more work, but it results in less wasted effort overall 23:16:36 (It seems like less work to me) 23:16:37 a memorandum? 23:16:42 a memo 23:16:44 ah 23:16:55 like, a short record of what we think 23:17:48 ah, right, every time the design phase is on. good idea 23:17:49 what i've found tends not to work is to make a large patchset/pull request that contains the implementation of the new design plus all the changes that refactor existing stuff to use it 23:19:22 ok 23:19:30 so you prefer those two things to split? so the refactoring phase happens prior to that and then the new implementation lands in another PR? 23:19:31 also i've found it important to make the design as small and simple as possible, at least at first. just big enough to make a few concrete proofs of concept work 23:19:44 Because then fixes to the design conflict with the new implementation? 23:20:02 teor: not sure what you're saying here? 23:21:04 My experience is that changes to the refactor need changes to the new implementation 23:21:23 And so if the new implementation is on top of the refactor, those changes conflict 23:21:38 * on top of the refactor in the same branch 23:21:42 teor: yes, i accept that kind of rework as a necessary cost to being able to implement things incrementally in a sustainable way 23:21:53 That said, I am also wary of merging code that has no implementation 23:22:02 * no connection with any other code 23:23:11 I think a lot of time, you need preliminary refactoring before you can even start on the new design. 23:23:14 yeah, so i think merging the preliminary new design together with a few migrations of existing code to use it might be best 23:23:32 like, the existing code has so much spaghetti and debt that it needs to get cleaned up before it can get replaced 23:23:34 nickm: that happens sometimes, but not always 23:25:11 isn't this something that might partially be caught with the 3#: do proof of concept work phase of what was just discussed? 23:25:46 ahf: somewhat, i think 23:26:11 cool, so we can try it out and see how much that shows up with that iteration model in mind? 23:26:32 oftentimes it's possible to design a new abstraction to cover the "easy" stuff, migrate that easy stuff as a proof of concept, then incrementally refator and migrate thet harder stuff 23:26:51 yeah 23:26:52 and iterate on the design if it turns out the harder stuff needs changes to the design of the new abstraction 23:27:30 yeah 23:27:38 like for the control.c reply stuff, the kvline-based abstraction i've made seems adequate for cutting over some simpler stuff as a proof of concept 23:27:41 t 23:27:56 there's some hairy stuff with the onion services stuff that will need a lot of refactoring before it can be migrated 23:28:18 maybe the kvline abstraction will need to be redesigned slightly to accommodate that, maybe not 23:29:14 seems reasonable to me 23:29:45 should we jump to "2.2. How can we collaborate on the design?" or do we want to add more to #2.1? 23:31:07 on 2.1 I'm okay with what I'm hearing; I think we'll need to iterate till we're on the same page for the details. 23:31:12 let's do 2.2? 23:31:14 It is related to what was just discussed, right? 23:31:17 it is 23:31:40 this one i have a bit of a hard time with since i haven't been in on this sponsor, so i don't know what you have done until now 23:31:57 I am +1 on the idea of pairing early. 23:32:04 it needs to be pretty involved, though. 23:32:23 close pairing? 23:32:38 frequent communication is needed for sure 23:32:41 i think it doesn't need to be continual screen sharing or voice chat, but maybe checking in several times a week if that works out schedule-wise 23:32:44 yeah. we can take some time on designs, but we can't afford putting everything on hold for weeks at a time 23:32:47 right 23:32:56 it needs to be more frequently than once a week 23:33:40 that's hard for the 3 of us together, but should be easier for us pairwise? 23:34:08 pairwise does sound a bit more attractive to me unless everybody is working together on the exact same thing 23:34:20 ticket comments seem to be working well for #29211 23:34:44 it works when everything is moving smoothly, but I don't think it will work for design, or for difficult discussions 23:35:02 sometimes having a conversation with <12 hour latency is needed 23:35:59 Sure. I think it's ok to default to ticket comments, and work more closely as needed. 23:36:52 what is more closely here? to have a quick irc session about it? 23:37:12 ahf: i think whatever works for the people involved 23:37:23 nod 23:37:58 I think we ought to be available for multiple pairwise discussions a week -- not necessarily every week, but when it's necessary. 23:38:07 nickm: what do you think would be smart to have here for the cases you mentioned where you want to make progress on the design or have difficult discussions? 23:38:11 ok, then we trust that each pair working on the stuff decides how communication will happen 23:38:14 some specific check-in times or? 23:38:41 maybe when starting to work together the pair should discuss and agree on how to communicate for the work 23:38:44 gaba: yeah, it sounds to me also that it makes sense that each pair figures out some check in times that works for both parties 23:38:52 also sometimes these small consversations work better in private. i know our default is for transparency, but we don't have to be transparent about every little detail, as long as the important stuff is publicly summarized 23:38:58 +1 23:39:05 ok 23:39:10 catalyst: very much agreed, i am a bit fan of PM's too 23:39:10 I think that the people involved can arrange stuff as needed 23:39:46 great 23:39:51 thanks gaba for writing these things down! 23:39:57 teor: does this seem plausible to you? 23:40:51 Seems fine to me. If the communication isn't working, we can take it to a sponsor 31 meeting. (And call one early, if needed.) 23:40:58 yep 23:40:59 ok 23:41:01 cool! 23:41:02 sounds good 23:41:09 item #3 seems like there is already some good stuff on it 23:41:16 3. What does a pull request need before it gets a review? 23:41:35 on to question #3 -- I would volunteer to put it on a wiki but I have committed to too many things this week. 23:41:37 there is a question from nickm to catalyst on it in the end, but i think the description there looks good 23:41:54 i was gonna ask where we want it put? on the network team page? 23:42:03 this reads to me more like a general network team thing 23:42:10 yeah 23:42:26 i can put it there. a "What is a good PR" section 23:42:28 yes, as a draft policy? 23:42:43 Or should we just post a link to the network-team list? 23:43:04 also there are two meanings of this list: one is "what should you do before you ask for a review", and the other is "under what circumstances should you say 'i won't review this, it doesn't have----'" 23:43:28 I think that it's reasonable for us to expect all this stuff from things that people on the team write, and we should do all this stuff from one another 23:43:34 *for one another 23:43:45 but we should be less stringent on volunteers 23:43:58 this is more of a "what do we commit to check ourselves" as I understand it 23:44:14 teor: we could do it as a draft policy; i think i might have assumed these things for a while, but it never hurts to have them written down 23:44:21 nickm: yes, with the understanding that we only have limited time to help volunteers, but we do as much as we can spare 23:44:34 yeah, it might be good to check with other people on the team before making a team policy ;-) 23:44:39 yeah 23:44:52 we should be clear what exactly we mean by the list if we want to make it a policy 23:45:15 ahf: would you like to kick off a discussion on the mailing list? 23:45:24 i can do that, yes 23:45:29 ty 23:45:30 it's gonna be after some sleep, but i have noted it down now 23:45:56 great 23:46:03 fwiw, I based my list on a checklist I made myself after last week's meeting, of the form "before needs_review, check this:" 23:46:03 let's continue that discussion with the rest of the team then 23:46:41 4. How can we keep our write/review/revise loop active and productive? 23:47:08 I think that the regular communication we talked about above will help 23:47:13 yes 23:47:20 i think this one gets better with the meetings every 14 days and in that we need to add communication between the pairs? 23:47:23 yeah 23:47:29 does everybody agree with that? 23:47:56 yes 23:48:01 catalyst: ^^ 23:48:22 ahf: yea 23:48:28 great 23:48:38 5. Can we review all tickets on time? 23:48:41 sounds like this one is good 23:48:50 it's okay with me. 23:48:52 so we go to> 6. Can we accomplish all commited on time? 23:49:27 it seems that what we are lacking the most is documentation 23:49:30 complicated question: I think the answer is "yes" -- what is required that isn't done is the documentation we promised. 23:49:31 i haven't read the proposals so i don't know what is must-do here 23:49:48 We _should_ do more modularization too, and land the refactorings that will help us do it. 23:49:50 Starting in line 204 o the pad we have the deliverables 23:50:01 with a list of what already have been done, what is in the roadmap and what is not in the roadmap 23:50:10 ah, right. thanks gaba 23:50:11 yes 23:51:17 (Can we take a 5 minute break soon if we're not going to end at 0000 UTC ?) 23:51:31 and the sponsor ends in ~20ish days? 23:51:48 nickm: it is OK with me 23:51:49 sponsor ends at the end of novmber 23:51:52 maybe before next item? 23:51:53 +1 to 5 min break 23:52:14 Sounds good 23:52:18 6 and 7 are quite related 23:52:28 a reminder that is quite late where ahf is so finishing soon is good 23:52:42 i am good. i slept late today for this reason 23:52:49 and i can sleep late tomorrow 23:52:56 ok. 5 min then? 23:53:01 ok, let's do 5 min break o/ 23:53:07 ok, I'll be back in 5 23:58:00 o/ 23:58:23 we are in section: 6. Can we accomplish all commited on time? 23:59:02 ok 23:59:22 I feel like the answer is "yes, we can do the docs remaining in the proposal, and they are the only essential item" 23:59:25 maybe we can do item 7. and then we will know this one 23:59:33 yes 23:59:44 But there is another answer about which refactoring and modularity we can do in the time remaining 23:59:45 what teor said 23:59:54 ok, let's go to #7: Next steps for the rest of the project (3 months) 00:00:26 teor seems to agree with nickm's suggestions there 00:00:31 catalyst: you have some thoughts here? 00:02:17 (I do not intend the list of items to preclude continuing to work on existing refactoring stuff fwiw) 00:02:24 how much time do we have remaining? 00:02:32 (for the project, not the meeting) 00:02:38 2 1/2 months 00:02:39 roughly 2.5 months, unless we ask for a no-cost extension 00:03:14 how many staff hours / days do we have remaining? 00:03:45 just a sec, let me confirm 00:04:29 have 2 1/2 engineers full time 00:04:44 for those 2 1/2 months 00:05:08 the idea was to have nick full time on this, catalyst 90% and teor 60% of their time 00:06:14 Hmm so I should get more involved in Sponsor 27? 00:06:28 teor: that was the plan in sweden, right? 00:08:01 so does everybody agree on what is in line 95 about what we should be doing next? 00:08:15 should we discuss each of those items here or start drafting what we mean by them? 00:08:43 (Ok, my last Sponsor 27 work took way less time than I expected, so I should talk with asn and dgoulet about what I should do.) 00:08:54 gaba: sounds reasonable 00:09:06 what is the goal? figure out which tickets for each of the 3 items? 00:09:07 (Maybe some chutney/CI/stem/etc stuff is billable to 27? I do not know) 00:09:23 I'd like to figure out what we do between now and our next meeting for each of those three items 00:10:33 like, not exhaustively... 00:10:39 yes 00:10:42 nod 00:10:45 ... but what we do to make sure we've made progress, and what progress we want to see 00:11:00 should the next 2 weeks be focus on documentation and find what else needs to be modularized? 00:11:22 catalyst: any thought on this? 00:11:41 i think doing all 3 could be reasonable; the rationale for starting discussion of c style now was to give the rest of the team time to mull it over 00:11:55 i'd like to make more progress on control.c, which seems achievable now that my review load has decreased 00:12:03 is it possible to do those 3 things at tha same time then? 00:12:28 control.c is not in any of those 3 things to include next, right? 00:12:47 i would include it under "modularization to do in 0.4.3" possibly 00:13:42 I think that existing control.c and config.c plans fit into okay to work on, so long as we are making progress on the other stuff 00:14:01 (for config.c, I plan to only be doing followup as requested by teor and catalyst) 00:14:25 i definitely want to have the C style improvements, and i forsee some friction 00:14:27 What should I be coding? 00:14:28 is it okay if I propose some ways to make progress on this stuff? 00:14:39 please do nickm 00:14:59 teor: is there anything in particular you super want to code in this area? if so great. 00:15:08 if not, let's identify modularization opportunities 00:15:12 (is that a good answer?) 00:15:27 Do we have a draft list? 00:15:49 I'm giong to switch to writing on the pad for a moment ... 00:16:41 line 102 teor 00:18:10 i've tried to write a draft of how we could make initial progress on each point 00:18:32 now i'm looking at the s31 tickets to see if there are any modularization items that stand out 00:18:51 #3 seems a bit like something we can also bring up at a network team meeting? 00:18:59 with some pre-discussion on a mailing list? 00:19:42 yes but I don't think we should wait till next monday. Also teor can't make the regular meeting times. so we should probably do the pre-discussion early? 00:19:51 right 00:20:10 do we need anything else in each of this items to be able to estimate and plan work? 00:20:31 we need to know who does each of these things 00:20:43 like, who does the drafting and discussoin, who writes outlines, etc. 00:20:51 I'm okay doing whatever nobody else wants to do here 00:21:22 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&sponsor=Sponsor31-can&sponsor=Sponsor31-must&group=milestone&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -- all tickets currently labeled sponsor31 . some of 00:21:28 these are modularization, some are just refactoring 00:21:41 teor, catalyst: any thoughts about this? 00:23:35 Seems like a good way of moving forward, let's assign people to each task 00:23:36 sorry, which "this"? 00:23:55 that list of things to do 00:25:53 yeah i guess that works. i'm not a fan of individual assignments for these though 00:26:08 you want pairwise assignments here? 00:26:15 maybe we can assign a lead person but each task is a collaborative effort? 00:26:20 +1 00:26:29 yes, maybe not assignments but somebody that can move the item forward and give progress report in next meeting 00:26:36 yes, what you just said :) 00:27:14 in that case: does anybody want to _not_ be involved in one of these? and would anybody especially like to lead any of them in particular? 00:27:45 ok, in next meeting we can expect something figure out in each task and a better idea of what is that we are doing there. 00:27:48 (I am willing to lead anywhere from none to all, whatever folks prefer.) 00:28:13 (though "all" would not be my ideal choice) 00:28:22 i have opinions about C style but i'm not comfortable leading it for various reasons 00:28:43 i think you would be very good to have in on that one, catalyst 00:28:51 catalyst: are you okay leading it among the three of us, following the steps we outline under #3 on the pad? 00:29:08 like, enumerating possible style changes, making sure we design a poll, making sure that we send it out? 00:29:26 catalyst is saying they do not feel comfortable leading that one. 00:29:29 ok 00:29:31 what about any of the other 2? 00:30:10 teor, nickm: which one do you want to coordinate? 00:30:25 we are almost done people :) 00:30:34 how about this: we enumerate any constraints we have, and gaba or ahf assigns us. 00:30:37 I am happy to coordinate the brainstorm on possible refactors 00:30:42 Like I said, I am okay with any or none of these 00:30:48 (as being coordinator) 00:30:54 i'm ok with coordinating (1) or (2) 00:30:55 ok 00:30:59 sounds good 00:31:00 I don't think I know enough about the documentation 00:31:15 are there tickets for the documentation work? 00:31:22 catalyst: what about you doing 2, nickm doing 1 and teor doing 3? 00:31:58 I'd rather do 2 00:31:58 or teor does 2, catalyst does 1, I do 3? 00:32:03 hehe, ok 00:32:08 :-) 00:32:15 catalyst: Therea re some tickets for documentation 00:32:16 *are some 00:32:18 ok i'll do (1) 00:32:46 catalyst: want me to email you a list of tickets and you can kick off our discussion? 00:33:23 we do not strictly need to do any particular item, just "improve[d] documentation for those modules" 00:33:28 nickm: would you be willing to tag them with something reasonable in trac? 00:33:47 catalyst: ok. I will miss some. 00:33:48 s31-docs? 00:34:06 nickm: sure 00:34:11 ok, anything else? it seems we do not need an extension. 00:34:44 i don't know what to do with that one. i guess that is something we know more about when we get closer? or maybe we can already now say we don't need it? 00:34:45 catalyst: I will also make sure I get must/vs should set right on them. 00:35:08 nickm: that would be great. thanks 00:35:15 I'll email you and teor when I'm done 00:35:48 nickm: please cc me. thanks :) 00:35:53 Have we spent enough hours on this project? 00:35:53 nickm: thanks 00:35:58 will do 00:36:06 That's another way to check if we need a no-cost extension 00:36:25 mmm, the project ends at the end of november 00:36:40 we need an extension if there is any deliverable that we can not do on time 00:36:47 but it seems that we are fine so far 00:37:43 cool 00:37:56 oh ok, so no worries about spending time 00:39:15 ok, are we done? :) 00:39:48 do we have anything else? 00:40:07 it seems we are fine 00:40:10 I will go by the report again 00:40:13 could we get a "Sponsor31" keyword so we don't have to search on both "Sponsor31-can" and "sponsor31-must"? 00:40:14 as may have missed some tickets... 00:40:19 and will check with you all again 00:40:45 catalyst: i requested to get one added but didn't hear from people about it 00:40:54 gaba: ah ok thanks 00:40:56 is this the trac admins that needs to do it? 00:41:03 we can just use a kewyrod, yes 00:41:06 ahf: yes 00:41:18 yeah, keywords are probably more easy 00:41:33 ok, cool, if nobody have anything else i'm gonna end the meeting with the bot 00:42:00 +1 00:42:05 cool 00:42:08 #endmeeting