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