13:28:43 <nickm> #startmeeting weekly network team meeting 13:28:43 <MeetBot> Meeting started Wed Mar 23 13:28:43 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:28:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:28:44 <armadev> how is that now 13:28:53 <nickm> Hi all! Let's do quick checkin. 13:28:59 <armadev> ok, i'll save the undirected chit-chat now that we are official :) 13:29:18 <nickm> I've been working on my modularity documentation, and corresponding implementation. Mostly though I've been reviewing and merging and etc etc etc 13:29:24 <nickm> and bugfixing etc 13:29:41 <nickm> also I got coverity autobuilds to happen three times a week. We can launch others as desired. 13:29:44 <nickm> up to 8 per week 13:29:46 <nickm> total 13:29:53 <armadev> neat! 13:29:54 <asn> hello friends :) 13:29:59 <nickm> this may be useful: https://people.torproject.org/~nickm/tor-auto/ 13:30:12 <dgoulet> o/ 13:30:36 <nickm> In the coming week I'll be doing more triage and planning things with isabela and everyone on the team, and I'll be finishing up the modularity ideas and v1 implementation for most (all??) of them. 13:30:43 <nickm> Also I hope to release 0282rc 13:31:01 <asn> modularity ideas are the ideas in: Subject: Updated draft: improved modularity in tor. 13:31:03 <asn> ? 13:31:17 <nickm> I'll need help; I'm relying on Sebastian and Yawning there; thanks for helping! 13:31:23 <nickm> (help with sponsor S eom stuff) 13:31:35 <nickm> asn: yes, and I sent the extra sections which I had forgotten to add before. 13:31:46 <asn> ack it's on my TOREAD list 13:32:01 <athena> hi meeting; looks like we got the hair-raising but actually harmless #18570 merged this past week (but it needs code review for backport to 0.2.7; on it); now digging into some code reviews (working on #7478) 13:32:10 <asn> it seems like lots of work! 13:32:24 <asn> i mean implementing all those backend abstractions and stuff 13:32:45 <asn> not all of them are necessary for minimum viable product wrt sponsor, right?! 13:33:15 <nickm> right 13:33:17 <nickm> but 13:33:22 <nickm> I'd prefer to do it right 13:33:27 <nickm> and that's it for me 13:33:44 <asn> ack 13:34:22 <asn> if this is something we start implementing RSN, then maybe we should send the plan to the mailing list RSN (for example, dgoulet was not on that thread). 13:34:27 <asn> i can go next! 13:34:44 <nickm> I'm planning to. Wanted to get more feedback 1st 13:34:46 <nickm> asn: go for it 13:34:57 <asn> during the past week I did some guard research. we have a meeting with ola bini and team in 90 mins. 13:35:06 <asn> it would be great if more people attend, I think. 13:35:13 <asn> since we are now going to talk about how to implement this thing in tor. 13:35:20 <asn> and they are looking for the right places to hook their code AFAIK 13:35:21 * dgoulet plans to attend 13:35:26 <asn> great :) 13:35:33 <asn> i also did some hackerone triaging. need to do lots more. 13:35:36 <nickm> Is there a missing step there? What's the best writeup of the design? 13:36:00 <asn> nickm: it's the prop259 spec on their github repo. 13:36:17 <asn> nickm: you are right that we didn't send the final version to the mailing list. 13:36:18 <nickm> Has it been sent to tor-dev? Is there a pull request or something? Can you link? 13:36:23 <asn> yes sec 13:36:29 <nickm> #action asn publish the latest prop259 revision 13:36:36 <nickm> #action nickm publich the modularity document as it stands 13:36:43 <asn> i expect the spec to change slightly as the implementation proceeds 13:36:59 <asn> because the algorithm should be adapted to the little-t-tor networking architecture 13:37:00 <nickm> sure, but right now I'm planning to go to this meeting with no idea about what the actual design is. :) 13:37:05 <asn> ack 13:37:31 <asn> this is it: https://github.com/twstrike/torspec/blob/review/proposals/259-guard-selection.txt 13:37:36 <asn> i will post it to the mailing list as you suggested. 13:37:54 <asn> ehm so there is that with the guards. 13:38:07 <asn> finally I also did some work on prop224 13:38:16 <asn> specifically on the cell formats. 13:38:33 <asn> i have a torspec branch with initial changes here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010561.html 13:38:50 <asn> the branch contains changes in the ntor section because it was unfinished. someone more cryptographically adept than me should look into it. 13:38:57 <nickm> #action examine/merge asn's changes in https://lists.torproject.org/pipermail/tor-dev/2016-March/010561.html 13:39:02 <asn> we should also send the new prop224 to the mailing list after we work more on it. 13:39:12 <asn> #action send new prop224 to mailing list when it's done 13:39:25 <asn> i also started a thread about more singificant changes to the cell logic 13:39:30 <asn> here it is https://lists.torproject.org/pipermail/tor-dev/2016-March/010560.html 13:39:47 <asn> since then we have decided we are going to keep backwarsd compability. so (a) is answered. 13:40:02 <asn> but we are still not sure about the UPDATE-KEYS-SUBCMD mechanism and whetehr we should keep it. 13:40:07 <asn> i didn't receive much feedback unfortunately 13:40:14 <asn> i thought about it a bit more 13:40:19 <nickm> armadev: there are open what-does-roger think questions there :) 13:40:42 <dgoulet> asn: I still want to send you some but I realized I needed to think about it more and then LibrePLanet happened :S 13:40:47 <dgoulet> asn: sothis week for sure 13:40:55 <asn> i'm currently leaing forward removing UPDATE-KEYS-SUBCMD 13:41:04 <asn> because i think INTRODUCE1 replays are not that dangerous 13:41:30 <asn> the current code actually says that the only reason we detect replays is because the same bona fide client might accidentally send the same INTRODUCE1 cell twice, and we don't want to connect twice. 13:41:39 <asn> but I need to think more. 13:41:46 <asn> the thread has much more background 13:41:49 <nickm> I'm nervous TBH. I think that this could be one of those places where a little harmless-looking hole can be widened into something worse by people smarter than us. 13:42:09 <asn> that's true. 13:42:16 <asn> we need to think more. 13:42:21 <asn> anyway this has been my week 13:42:28 <nickm> ack. next? 13:42:45 <armadev> i can go next 13:42:56 <armadev> I actually wrote a tiny bit of Tor code lately (#18332) 13:43:05 <armadev> I mostly have questions though (from thinking this morning): 13:43:09 <armadev> a) Where is the 0.2.8 timeline posted? Maybe it should be on the network team t 13:43:10 <armadev> rac page? Or somewhere else? 13:43:20 <armadev> b) I see athena mentioning backporting the #18570 patch. Do we (you) have consensus on what is worth backporting? Should we (you)? 13:43:32 <armadev> (i would argue that the patch doesn't want a backport) 13:43:36 <nickm> #item discuss backport strategy 13:43:41 <nickm> #item discuss 0.2.8 timeline 13:44:05 <armadev> ok that's it for me. i'm sure i'll come up with more as we go. 13:44:05 <nickm> (holding those for discussion period) 13:44:52 <nickm> next? 13:44:58 <armadev> (i see the questions for me about prop224. i am being a bad person and not being able to keep the 224 design in my head. that makes it hard to usefully answer questions. :/ ) 13:45:40 * dgoulet can go 13:46:20 <nickm> #action asn explains the prop224 questions to arma? :) 13:46:22 <nickm> dgoulet: go! 13:47:13 <dgoulet> code review and a bit of patches last week, got sucked in LibrePlanet during friday/weekend/monday and I basically catched up on things yesterday. I plan to continue prop224 implementation today as I'm moving to do the cache work for HSDir. 13:47:59 <dgoulet> so I still need to answer bunch of people on email including GsoC stuff for HS but hoping to jump back in the coding arena 13:48:00 <dgoulet> pp 13:48:02 <dgoulet> --* 13:48:38 <nickm> #item discuss stuff we should do _before_ jumping into 0.2.9 tasks :) 13:48:41 <isabela> I can go next 13:48:44 <nickm> go! 13:48:53 <armadev> #item summarize promising gsoc students for network team topics? 13:49:00 <isabela> I migrated all the info you added into the spreadsheet back to trac (thanks for doing it) 13:49:22 <isabela> worked on the release guidelines first draft with nick and y'all has it now 13:49:49 <isabela> trying to organize the next step on triagging (need some answers to help guide it / email I sent yesterday) 13:49:52 <isabela> we have a list now 13:50:01 <isabela> we should talk about it :) maybe discussion time? 13:50:03 <nickm> #item discuss draft plans for 029 release/triage/etc. 13:50:06 <nickm> Yawning: you around? :) 13:50:15 * isabela done 13:50:34 <nickm> mikeperry: I bet you're asleep. 13:50:39 <nickm> better meeting time next week. 13:50:50 <isabela> yep, 7am for both mikeperry and Yawning 13:50:51 <nickm> teor: I bet you're asleep too, or will soon be. gnight :) 13:51:12 <nickm> well, Yawning was awake an hour ago if I'm reading other channel logs right. 13:51:21 <nickm> So if he's still up he can check in 13:51:28 <nickm> either way, moving on to discussion? 13:51:37 <Sebastian> (I'm here, got nothing to report. But I'm free to work on the stuff I promised nickm tomorrow.) 13:51:55 <nickm> so many thanks Sebastian 13:52:56 <nickm> here's the discussion items mentioned above: http://paste.debian.net/418358/ 13:53:20 <nickm> let's do the gsoc student one first since it's not related to the others 13:53:39 <isabela> ok 13:53:40 <nickm> armadev: could you just mention the topic areas that might need mentors? 13:54:04 <nickm> I am not mentoring gsoc this summer myself; I'm getting my "working with students" out of my system this term with the MIT students 13:54:11 <armadev> i cannot! i know nothing. except that we are doing gsoc and maybe some people have discussed something. 13:54:32 <nickm> ah. Then maybe there's nothing to discuss right now? Or is there? Does somebody know something? :) 13:54:45 <armadev> it might be that zero people from the network team have paid any attention to gsoc stuff. that would be worth knowing too i guess. 13:54:56 <asn> I know about two potential students and maybe a third one. 13:54:59 <isabela> I guess what we should do is get a list with atagar of projects related to network team? 13:55:19 <asn> there is one student interested in writing a standalone tor-keygen, a replacement for "tor --keygen". 13:55:27 <nickm> #action get quick list of network-team-related projects 13:55:27 <asn> there is one student interested in working on TAILS server mode. 13:55:34 <isabela> armadev: I think atagar is trying to match mentors with students 13:55:43 <nickm> in that case, 13:55:44 <asn> there is one student interested in Ahmia and elastic search (not network-team related). 13:55:52 <dgoulet> I'm following the "tor-keygen" project 13:56:01 <nickm> #action somebody ask atagar if there are network team projects without enough adequate associated possible mentors 13:56:05 <asn> these are the ones I know. I'm mainly following the TAILS server one now. 13:56:16 <nickm> moving on to the next topic? 13:56:35 <asn> sure 13:56:40 <armadev> sounds good. there's no reason to pick a network-team gsoc student. but if you (yes you) want one, do feel free! 13:56:46 <nickm> So, I'm going to combine "0.2.8 timeline" and "stuff we should do _before_ jumping into 0.2.9 tasks. 13:57:04 <isabela> ok 13:57:07 <nickm> Right now, 0.2.8 comes out "when it's ready". And I'm concerned about "when it's ready". 13:57:42 <nickm> During check-in above saw a bunch of people listing their next tasks as "program/review/etc this neat/important thing for 0.2.9" 13:57:50 <nickm> s/saw/I saw/ 13:58:22 <nickm> I'm starting to worry that 0.2.8 release, and 0.2.9 triage, are kind of falling off of people's radars. 13:59:12 <nickm> If everybody else jumps into 0.2.9 without me, and/or without triage, bad stuff will happen. Most obviously, 0.2.8 will be slow, and I'll get behind in helping with 0.2.9, so 0.2.9 patches won't get merged. 13:59:46 <nickm> I'm wondering if there's any good way for us to focus some effort as a team on 0.2.9 planning/triage and 0.2.8 release stuff. 13:59:54 <armadev> in the distant past, for a while, i was the stable release manager and nickm was the new release manager 14:00:07 <armadev> this wasn't official or anything, it just happened that way 14:00:31 <armadev> (i wonder if somebody wants to be the 0.2.8 person so nickm doesn't have to be) 14:00:55 <nickm> I'm not thinking I should pass off 0.2.8 just yet, but I don't want to solo it. 14:01:16 <nickm> I'd love for somebody else with a suitably conservative attitude to take over 0.2.7 14:01:19 <isabela> +1 to focusing on finishing 028 and triaging 029 14:01:33 <armadev> good thought re 0.2.7 14:01:55 <dgoulet> nickm: you want more people to merge things for 028 in parallel or you just want the team to review/do patch for tickets and put them in "need nick merge" ? 14:02:11 <dgoulet> (former implies much more actually, commit access, blablaablab) 14:02:18 <nickm> Merging isn't the hard part. 14:02:30 <nickm> Deciding what needs to go in the RC is hard; fixing bugs is hard; etc. 14:02:53 <nickm> I labeled some things as must-fix-before-028-rc. 14:03:07 <nickm> Probably some don't have to be. 14:03:39 <nickm> currently there are 7 left. 14:03:51 <nickm> https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~must-fix-before-028-rc&component=Tor&group=milestone&col=id&col=summary&col=keywords&col=component&col=status&col=type&col=priority&col=milestone&col=version&report=23&order=priority 14:03:56 <dgoulet> yeah and almost all teor :S 14:04:04 <nickm> 2 are needs_info, so forget about those. 14:05:03 <nickm> Options are: 1) somebody helps teor out by fixing one or two. 2) we delay the release candidate. 3) we decide that some of them don't need to get fixed in the release candidate. 4) we wait patiently until teor has time. 14:05:14 <asn> i can take over #18479 14:05:15 <nickm> I think a combination of 1 and 3 is best, with 2 and 4 being less good 14:05:21 <athena> by "take over 0.2.7", do you mean "take over making decisions about what should be backported/merged?" 14:05:24 <nickm> asn: great; say so on the ticket? 14:05:35 <nickm> athena: yes, and doing the backports / merges / releases. 14:05:36 <armadev> 5) we put out an alpha in the mean time, so the release candidate won't have so much new stuff in it 14:05:48 <armadev> (easy for me to say. might not be the best use of time. but it is an option.) 14:05:57 <isabela> (we need to have owners on tickets) 14:06:06 <athena> right; i can take that one on for you if you like 14:06:44 <nickm> athena: great. Would you like to start by going over all the tickets in maint-0.2.7 and saying which you think should get backported, which not? armadev and weasel will have opinions, I bet. :) 14:06:56 <nickm> saying "no backport" is usually a good call. 14:07:14 <armadev> right. this bleeds into the backport discussion which i will not begin quite yet. :) 14:07:55 <nickm> I've made myself owner on #18397 and declared it not to block the rc 14:07:56 <dgoulet> maybe #18481 could be pushed to 029 (maybe) ? 14:07:59 <armadev> so, re 0.2.8 timeline, it sounds like there *is* no timeline? was there ever one, and we are now pretending there isn't because we didn't follow it? 14:08:26 <nickm> timeline was freeze-start-of-march, then rc mid-march 14:08:30 <isabela> armadev: yes, we are trying to build such guideline (timeline) for all releases 14:08:33 <nickm> we did the freeze ontime. 14:08:36 <nickm> the rc is late. 14:08:49 <nickm> I've marked #18370 as not blocking the rc 14:09:13 <nickm> re #18481 I'd like teor's call on that. dgoulet: ask on the ticket, "can this wait for 0.2.9 if it isn't done in time for the rc?" 14:09:14 <isabela> armadev: there was a calendar, but very broad 14:09:27 <dgoulet> nickm: ack 14:09:45 <nickm> dgoulet: alternatively re #18481 we can just do it. I think the fix was to rename the config option and add a couple more checks 14:09:58 <isabela> armadev: we are trying to get schedule in place for everyone to work around it and I hope once we do it will go in the wiki 14:10:07 <dgoulet> nickm: that part made me worried: " This also involves carefully sanity checking any user-supplied values to these options." 14:10:20 <dgoulet> nickm: what are the right values...? 14:10:26 <athena> nickm: sure; these 027 tickets? https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&component=Tor&milestone=Tor%3A+0.2.7.x-final&col=id&col=summary&col=component&col=milestone&col=type&col=status&col=priority&order=priority 14:10:27 <nickm> dgoulet: make something up, see if anybody argues? :) 14:10:43 <nickm> athena: yes, assuming they are all backports 14:10:57 <nickm> if anything isn't a backport it belongs in 0.2.somethingelse 14:11:13 <nickm> dgoulet: like, not super super fast 14:11:21 <nickm> dgoulet: if people retry super slow, that's their choice 14:11:32 <dgoulet> nickm: ok I'll take the ticket and see where I can get us 14:11:36 <athena> sure; so the algorithm is "for each ticket, decide if it really is a backport, if so, decide if it should be merged, else assign the ticket to a different version" ? 14:11:49 <nickm> yup! 14:12:16 <nickm> then if you want, maybe look through maint-0.2.[456] ? Or is that too ambitious? :) 14:12:48 <athena> i'll see what i can do 14:12:48 <nickm> #action athena bangs on 0.2.7 14:13:12 <nickm> oh. 0.2.4 and 0.2.5 are empty. There are a few things in 0.2.6. 14:13:25 <nickm> Maybe some of the 0.2.7 stuff should get into 0.2.6 as well; up to you. 14:13:54 <nickm> I _think_ #18351 might be just quieting the log in 0.2.8 14:13:56 <athena> you got it 14:13:58 <nickm> thanks 14:14:07 <nickm> I think #18489 is important to fix, sadly. 14:14:16 <nickm> #18517 has a workaround, but we should think about it more 14:14:20 <nickm> and I think we've talked about all the bugs now. 14:14:21 <nickm> great. 14:14:25 <nickm> Next topic? 14:14:42 <nickm> I think we did "discuss backport strategy", yeah? 14:14:49 <armadev> almost but not quite 14:15:09 <armadev> in general, i think the algorithm for a backport should be "is this the sort of thing we'd ask debian to put out an update for?" 14:15:14 <nickm> Suggestion: let's call the backport strategy "only the really important stuff." 14:15:15 <nickm> Yeah, that. 14:15:23 <armadev> so, "it's broken" is not a good enough reason to backport 14:15:35 <nickm> well, "it's a bug" is not a good enough reason. 14:15:36 <armadev> also in general, if we can tell people who want it to work better to upgrade, we should do that instead 14:15:44 <nickm> but "It's insecure" or "it crashes" is a good reason. 14:16:03 <nickm> "it crashes if you do some weird config option that never worked, and the patch is huuuuuge" would not IMO be a backport though 14:16:08 <armadev> we are winners if we decide to not backport stuff. each choice to backport a thing should be because we are convinced it's needed by people who can't upgrade yet. 14:16:29 <dgoulet> +1 14:16:33 <armadev> in general, focusing on backporting stuff rather than getting the new stable out quicker is a poor tradeoff 14:17:00 <armadev> doubly so for oldstable, since we should be thinking about who the audience is that cares whether we merge a thing into release-0.2.6 14:17:19 <armadev> athena: sound plausible? 14:17:53 <nickm> armadev: may I pastebin the above? 14:17:55 <armadev> yes 14:18:08 <armadev> also, i think we have actual guidelines for what to backport, written up somewhere 14:18:28 <nickm> #info here is a draft backport policy. http://paste.debian.net/418364/ 14:18:31 <armadev> also also, i am looking at changes/ in release-0.2.7, and it has all sorts of stuff that maybe we shouldn't have backported, and also, nobody is making a new 0.2.7 14:18:44 <isabela> nickm: nice I will make sure we have this in the wiki as well 14:19:07 <nickm> maybe then the backport policy should be stricter, like having one approver and one merger always. 14:19:08 <isabela> #action isabela to add backport policy to the wiki 14:19:18 <nickm> #idea two-person approval to backport? 14:19:38 <armadev> a nice side effect of a good backport policy is that it saves time and effort 14:19:48 <isabela> indeed 14:20:58 <armadev> isabela: you should spend a bit of effort trying to figure out if we already have a backport policy. i alas am not creative enough to think where we might have put it though. 14:21:16 <armadev> (already have one written i mean. we clearly don't follow it. :) 14:21:18 <isabela> ok, i will look in the wiki 14:21:22 <isabela> hehe 14:21:28 <armadev> ok, next topic? 14:22:03 <nickm> next topic is What are isabela's plans for making 0.2.9 go awesome? What do we all need to do to make sure those plans become even more right for us, and how do we follow through? 14:22:13 <isabela> ok 14:22:56 <isabela> next step is to start moving things out of the milestone 14:23:27 <athena> armadev: yes, sounds fine 14:23:30 <isabela> for that I need help setting 2 guiding points 14:23:34 <isabela> priority list 14:23:51 <isabela> and team capacity (how much work we can actually do in a week/month) 14:24:40 <isabela> https://storm.torproject.org/shared/71UUCvDgDA6q9lfdndAtRZoWQdjz4Wb8EoX0eLyBiYq 14:24:44 <isabela> section 3 there 14:25:33 <nickm> It looks like you've set priority 1: funded-must. 2: funded-can as we decide. 3: other sponsored work if we're aware of it. 4: other non-sponsored. 14:25:38 <nickm> is that correct? 14:26:08 <isabela> re: why R is below U and S - because U and S ends in Q3 but I guess one can argue that year 2 of R also ends in Q3? 14:26:23 <isabela> nickm: yes 14:26:33 <armadev> R stuff needs to be done each quarter for the PI meetings that happen each quarter 14:26:56 <armadev> we don't have specific tasks we promised to do by a given quarter, but waiting until 2017 to finish stuff is unwise 14:27:04 <isabela> ok 14:28:23 <isabela> nickm: about how to prioritize '-can' stuff - I believe we should check if the ticket is a dependency for other work, the tickeet priority (urgent).. is a combination of inputs 14:29:08 <isabela> and of course, if something urgent comes in we add it / and deal with the necessary rearrangement of plans to accomodate that 14:29:40 <isabela> again, the main thing that makes this all works are check in moments and keeping the tickets with the necessary info 14:30:19 <isabela> the team needs to be constant looking and thinking about it, so it does not go off track (and I can help with that here at the meetings) 14:30:52 <nickm> ok. 14:30:59 <isabela> question: should we aim for a 3 coding days per week? 14:31:10 <isabela> we can calibrate it if does not reflect reality 14:31:30 <nickm> I think it's a fair starting point. It would be wonderful to find out that we are far more productive than we think. 14:31:56 <nickm> and wonderful in any case to be able to accurately predict our time 14:32:18 <nickm> does everything in maint-0.2.9 have points now? 14:32:25 <nickm> err, in the milestone? 14:32:57 <isabela> nope 14:33:00 <asn> i'm not exactly sure what 3 coding days per week means. does this assume that everyone is full time and works 5 days a week normally? leaving 2 days for non-coding stuff? 14:33:24 <nickm> maybe everybody has their own number of days-per-week, depending on full/part time? 14:33:38 <asn> does "3 coding days a week" mean 70% coding time? 14:33:56 <nickm> I think maybe it means 60% (==3/5) coding time? 14:33:59 <asn> or 3/5 of your time working in tor should be coding time? 14:34:03 <isabela> asn: I need a number of how many hours to expect per person per week to calculate if the amount of work selected can be done 14:34:04 <asn> fair enough 14:34:09 <nickm> not "should be", "is estimated to be". 14:34:29 <nickm> Like, if we guess that nick is 6 one-day tasks, we should assume that nick will need 10 working-days to do them. 14:34:35 <isabela> this is all estimation we wont be checking if you indeed coded for 3 days and what days :) 14:34:46 <isabela> is for us to not over commit 14:34:58 <isabela> be realistic 14:35:15 <nickm> exactly. The goal is prediction and scheduling and planning, not fascism and micromanagement 14:36:24 <nickm> sound plausible? 14:36:27 <asn> plausible 14:36:42 <isabela> cool 14:37:01 <isabela> ok, to move on - that priority list looks ok? 3 days a week for coding is ok? 14:37:13 <isabela> if so, I will ask ppl to add points for those we dont have 14:37:23 <nickm> dgoulet: I share your worry about "only 2 days coding". But it's my reality. If everybody else does 5/5 days coding, I don't think I even get 1 day coding. :) 14:38:16 <asn> isabela: is days the right unit of measurement here? or hours? how many hours in a day? 7? 9? 14:38:31 <dgoulet> nickm: yeah more coding days means more patches to merge 14:38:32 <isabela> I think 8 14:38:40 <isabela> dgoulet: and review 14:38:51 <nickm> and more bugs to track down and fix 14:38:56 <armadev> i think there is one small task in a day 14:39:14 <armadev> so don't worry too much about how many hours are in that day 14:40:05 <nickm> all of these are fuzzy abstract ideas. ("day", "small task", etc. probably we won't be too precise. If we can get to within +/- 50%, we'll be doing far more accurate planning than we ever did before.) 14:40:10 <armadev> (hopefully everybody agrees with how big a small task is) 14:40:12 * asn has unconventional work schedule that's why he finds that question hard 14:40:13 <isabela> think about the size values we have for tickets: small == <1 day | medium == <1 week | large == +1week 14:40:25 <asn> ok 14:40:30 <asn> i see 14:40:31 <isabela> so, in a week you could fit two small tasks or one medium 14:40:38 <armadev> isabela: the storm page says "1 full day", not <1 day ? 14:40:48 <isabela> we can fix that 14:40:57 <armadev> great. now you know. :) 14:41:25 <nickm> isabela: should we be fiddling priorities too, or is that not useful right now (just points) 14:41:43 <isabela> so, if the team gives me a value for the week, 2 or 3 days. I can calculate the amount of work we are committing for the release and say we can add more work, we wont get it all done 14:42:00 <isabela> nickm: it is useful 14:43:10 <nickm> I'm doing a first pass for points now. 14:43:17 <nickm> what should everybody else be doing, and what are our next steps? 14:43:35 <nickm> And should we talk about how we'll be using the milestone? 14:43:42 <isabela> is that, update the tickets 14:43:52 <isabela> we can talk about it now or next meeting 14:44:20 <isabela> (I dont want to take over time, I think we still have other points for discussion) 14:44:38 <isabela> btw 14:44:39 <nickm> do we? 14:44:48 <nickm> Other points? 14:44:52 <isabela> i dont have the pad open 14:45:05 <isabela> did we cover everything? 14:45:20 <nickm> I think maybe we did? Are there other discussion points? 14:45:27 <isabela> ok 14:45:37 <nickm> #action somebody needs to go over this with the devs who weren't here. 14:45:38 <isabela> should we talk about milestones? 14:45:42 <nickm> let's! 14:45:47 <isabela> I also have a question about tickets workflow 14:46:06 <isabela> I think if we add 'need nicks review' we will mess with other teams workflow 14:46:29 <isabela> we might need something like this https://trac-hacks.org/wiki/MultipleWorkflowPlugin 14:46:48 <dgoulet> maybe "need_merge", "ready_merge", just to indicate that it has been reviewed and someone did Acked it ? 14:47:04 <isabela> should we run this by tor-dev list? 14:47:32 <nickm> i'm also okay with keywords if we use them well, but I understand how workflow is preferable. 14:48:29 <isabela> i think the steps dgoulet is suggesting can benefit all dev teams 14:48:51 <isabela> we can just email the list asking for objection? 14:48:58 <dgoulet> yup 14:48:59 <nickm> +1. Also we should be gentle in how we enforce those in trac. 14:49:12 <isabela> sim 14:49:19 <isabela> ok i can do that 14:49:27 <nickm> like, if somebody sees a ticket in 'new' with a patch and reviews it, let them move it straight into 'ready_to_merge' 14:49:40 <nickm> #action isabela asks about ready_for_merge 14:51:01 <nickm> Has everybody seen "Making traige stick" in the pad? I worry it will look like an authoritarian power grab, maybe. But also I worry that it's a process we might need. 14:51:13 <isabela> hehe 14:51:22 <nickm> Simplest idea is: nobody just puts things into the 0.2.9 milestone. 14:51:43 <isabela> once we close triage 14:52:04 <nickm> Instead, getting stuff into the 0.2.9 milestone requires some amount of discussion/pushback/whatever once triage is closed. 14:52:11 <armadev> makes sense. a (hopefully small) portion of each checkin can be looking at the tickets somebody wants to add into 0.2.9? 14:52:13 <nickm> This isn't a decision we should make in one day 14:52:19 <dgoulet> would putting things in "current milestone" _only_ if it has a owner is crazy? :) 14:52:22 <isabela> armadev: yes 14:52:29 <isabela> dgoulet: no 14:52:30 <armadev> is there, then, a way to mark a ticket as "we should discuss whether it should be in 0.2.9"? 14:52:38 <nickm> dgoulet: that would be a good prerequisite, but not a sufficient condition. 14:52:41 <nickm> armadev: I believe there should be. 14:53:01 <nickm> also next meeting is in 7 minutes I think. 14:53:20 <isabela> ok 14:53:30 <isabela> I can look into how we could apply such process 14:53:35 <isabela> and document it for more discussion 14:53:56 <nickm> I want to make sure this milestone thing is on everybody's radar. Please grumble at me/isa/arma/whoever if you think it's a completely horrible idea. Or use the pad to comment about what would be the difference between having it be bad and having it be good. 14:54:04 <nickm> any more for this meeting? 14:54:17 <asn> i moved a ticket to 0.2.9 yesterday because it was on 0.2.8 and it was too big of a task for now. i wonder what i should have done. maybe move it to 0.2.??. or to tor-untriaged? 14:54:36 <armadev> an un-named animal who doesn't like meetbot points out that moving from a broken 0.2.8.1-alpha to a release candidate is not the right definition of release candidate 14:54:37 <asn> although simple tasks are bound to be forgotten if we move them to 0.2.?? . 14:54:57 <isabela> that is why we are building these guidelines - hopefully they will be in the wiki and everyone will know what to do 14:54:58 <armadev> more in-between releases would be wise. maybe even for this one. 14:55:19 <armadev> (and that's why i was suggesting a person to manage the 0.2.8 process, so it doesn't have to distract nickm) 14:56:14 <dgoulet> asn: yes that! forgetting if in 0.2.?? is what I'm worried 14:56:41 <armadev> dgoulet: maybe an '0.2.9-wishlist' milestone or something? 14:56:45 <armadev> or is that better done as a tag 14:57:08 <nickm> maybe we move 0.2.??? into undecided, and make a new 0.2.next-wishlist ? 14:57:15 <nickm> dunno 14:57:28 <isabela> ? 14:57:44 <isabela> shouldnt we just have one backlog that is not yet ellected for a release? 14:58:09 <armadev> the question is, when somebody identifies a ticket that they think ought to be 0.2.9, but they're not allowed to just move it there (we just decided), how do they remember it? 14:58:10 <nickm> we could use "undecided" for that if we police it better. 14:59:29 <dgoulet> aren't we ending up in a more complex workflow here instead of re-triaging bugs as we go out of 0.2.9 ? 14:59:54 <nickm> okay, I'm going to call the meeting, since the next meeting is supposed to start now 14:59:56 <asn> [oops guard meeting starts now.] 14:59:59 <isabela> normally if somethign should be picked up next it should be at the top of the backlog 15:00:04 <nickm> let's keep talking about worksflow on #tor-project ? 15:00:05 <asn> i can move the meeting to #tor-project 15:00:07 <isabela> and you should have a single backlog 15:00:08 <asn> ah ok 15:00:13 <asn> you guys go to #tor-project! 15:00:16 <nickm> thanks everybody ! 15:00:17 <dgoulet> go 15:00:18 <isabela> hehhe 15:00:18 <nickm> #endmeeting