19:01:01 #startmeeting 19:01:01 Meeting started Wed Jun 18 19:01:01 2014 UTC. The chair is rl1987. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:01 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:07 * dgoulet not far as usual :) 19:01:16 hi dgoulet 19:01:35 So, we have a big release out. As soon as somebody can update the website, I'll announce. That's good 19:01:41 mikeperry: and yes, UBSan issues are only logged and not fatal 19:01:47 * GeKo shuts up now. 19:02:09 We have a couple of tricky 0.2.5 issues left, but I bet they'll be not too hard given a little effort and the diagnostic logs in 0.2.5.5.-alpha. 19:02:37 I think I should fork maint-0.2.5 and make master into Tor 0.2.6. Agree? 19:05:49 Assuming the answer is "yes". 19:06:08 #agreed I should make Tor 0.2.6 development start now 19:06:14 #idea or maybe it should be Tor 2.6 19:06:34 I th 19:06:48 I think 0.2.6 is more consistent with curent versioning scheme 19:06:51 I've been thinking about the "what happened with 0.2.5" question 19:07:09 yeah, think it's time for 0.2.6 19:07:19 on the one hand, since we did patch-freeze on 0.2.5, it's converged to goodness pretty well. 19:07:30 on the other hand, it took a while longer than I expected. 19:08:03 Part of me says that the answer is to prioritize patch review,. 19:08:20 or maybe the answer is to declare a timeline for patch freeze more rigorously. 19:08:27 or to defer more aggressively 19:08:37 or something else. 19:09:23 We have a lot of things that we'd like to do and call "0.2.6". Some of them -- maybe all, let's pretend -- could be achieved in 2014 and put into a stable release by december. 19:09:48 Assuming we want stable by december, do we need to declare patch freeze in september? 19:10:11 that wouldn't be enough time to implement all the stuff I want to do this year 19:10:30 otoh, if I plan to spend now through oct or nov implementing, I can't really try to stablize for dec. 19:10:47 athena: do you think it's more reasonable to start with deadlines, feature lists, or what? 19:10:50 others too 19:11:47 how 'independent' is core t-tor development from particular funder deliverables? (vague question is vague, but on topic) 19:12:38 somewhat. We try to structure deliverables so that they do not say things like "Feature XYZ is in a stable release" but rather "feature XYZ is in a release that users can use" or even easier "Feature XYZ is implemented" 19:12:51 hmm, features always take longer than one thinks they will 19:13:13 if we want less schedule slippage, perhaps a more rigorous freeze deadline is the right approach 19:14:31 I wonder whether we took so long because we had so many tickets in state "fix this after the freeze, it's important" 19:14:48 or because we had so many tickets in state "This has code, so it made it past the freeze, so we can merge it" 19:14:58 or something else 19:15:09 how could we find out? 19:17:11 I ask because the responses are different in those cases 19:17:30 if our problem is that we left too many bugs for too late, the response is "prioritize bugfixing, or be more ready to defer it" 19:17:57 if our problem is that we had to review and revise/merge too many things, the response is "Review patches more aggressively" 19:18:52 can we do some data analysis on trac tickets to have a broad view of what was going on? 19:19:14 I like that idea but I am not too sure of what to analyze 19:19:17 trac timeline should yield enough info to answer those particular questions, no? 19:19:20 any thoughts there? 19:19:38 rl1987: Is that something you'd like to explore? 19:20:03 I might look into this 19:20:11 if the keyword 'triaged' conveys enough info ('this is merge-ready', whatnot), maybe it would be possible 19:21:20 is there an REST API in trac? 19:21:40 (i assume not, but trac timeline is available for nasty harvesting, i think) 19:21:43 025-triaged means "we looked at this for 0.2.5 and didn't decide not to include it" 19:22:03 rl1987: I think there's some kind of XML api, but your guess about how to use it is as good as mine 19:24:52 I guess we could try to adopt _all teh solutions_ 19:25:26 (it wouldn't be a 'clean' job by any measure, i guess. so e.g. one would have to look when 025-triaged was added, and then cross-reference the changelog on git master. or something like that) 19:26:27 simultaneously prioritize bugfixes, triage early, prioritize code review for needs_review tickets, make a short list of features to implement, and set a timeline 19:26:39 not sure if that is sane 19:27:15 karsten: sorry i missed tor-weather :( miscommuncation w/ my wife, and I had no computer to send mail/irc 19:28:14 i will review lucyd's branch 19:29:29 having a list of 'features [we really want] to implement' makes a lot of sense, but that's of course pretty vague/generic 19:30:09 as in, these kinds of precise TODO lists really help, and i imagine they can scale to larger groups of people too. but, what do i know :P 19:30:27 old code is hairier, much low-hanging fruit of bugs have been fixed, natural tendency is to procrastinate debugging and play with shiny new stuff 19:30:45 yeah 19:30:50 for difficult bugs, get diagnostic patches in point releases earlier in cycle 19:30:52 maybe we should triage early, not late 19:31:15 athena: should we plan a triage time? we have historically done that much better when working at the same time 19:33:52 nickm: yeah, probably 19:33:59 ok. when's good for you? 19:34:05 I am unexpectedly free after this meeting. 19:34:18 and free at 2100 EDT plus epsilon 19:35:02 others are welcome to join in too 19:37:14 rl1987, wfn: Are you interested in trying to figure out how well 0.2.5 went (or didn't go?) 19:37:44 (from a science POV, I maybe shouldn't be the person seeing how well we did) 19:38:24 yes, I will try to do some data analysis 19:38:28 cool 19:38:43 what are the main questions to ask here? 19:38:47 nickm: honestly yes, but i'm really short on time. maybe after the gsoc mid terms, during/after the dev hackaton, or between midterms and that 19:38:49 "results soon" is probably better than "better results later" 19:38:54 i'll ping rl1987 when appropriate 19:38:59 2100EDT is good for me i think 19:39:34 rl1987: my main questions are, "What did we spend our time on since we declared patch freeze?" and "why did that take so long?" 19:39:43 athena: what questions do you want answered? 19:39:53 wfn: what about next week? I will be AFK this weekend. 19:40:27 were we bottlenecked on reviews or on bug fixes we committed to do in 025? 19:40:48 rl1987: possible. can't do much else before next week anyway. and, i might be away from irc / busy during monday/tuesday. let's SYN some time then. sorry, no promises :( 19:40:51 of the stuff we triaged into 025, were we too ambitious? 19:41:05 I found that tickets can be downloaded in CSV format, yay 19:41:29 when did we declare path freeze? 19:41:50 (as an addendum, this would be pretty sweet data to harvest, yes. as in, conclusions might be worthwhile / worth some kind of blog post, etc) 19:42:26 rl1987, wfn: Also, feel free to declare "We could not learn this because we needed trac to contain information XYZ, when it did in fact not contain that info" 19:43:07 yeah. this would be a very science-y conclusion indeed 19:44:08 #action will be working with wfn to figure out why it took so long to reach stable release after patch freeze. 19:44:12 also practical, since it would tell us what we need to record next time 19:44:29 I believe that the patch freeze was shortly after the last dev meeting. 19:44:34 athena: does that match your recollection? 19:45:05 rl1987: i'll just repeat again that i have a pretty hot todo list, and will prioritize other things instead of this thing until those things are done. :) 19:45:33 does patch freeze mean "no new patches will be accepted"? 19:45:56 wfn: allright, will see what I can do myself 19:46:15 It meant "Only feature patches already submitted will be considered. Bugfix patches are still okay if they are not too big, depending on the bug. We will try to fix more bugs; we will try to triage which ones are most important" 19:46:23 I think 19:46:59 See "New conventions for Tor ticket milestones" in tor-dev on feb 28 19:48:26 yeah, i think we patch-froze in march IIRC 19:48:46 #action nickm and athena will triage 0.2.6 tickets tonight around 2100 eastern, plus epsilon 19:49:49 ok. I think that we are close to winding up for this week. I bet that after athena and I try to triage we will have more to say 19:49:54 one thing: 19:50:54 athena: did you have a chance to look through any stuff for 0.2.6 in needs_review/revision? I mostly looked at a few of the things in needs_review that I wrote, and conscluded that they were needs_revision 19:51:11 *concluded 19:54:01 not yet; i keep meaning to rebase the scheduler against current master and have another read through it 19:54:41 any smaller things of yours pending, or is that the only one? 19:54:44 but my life is a productivity-slaying disaster of packing all my stuff into storage and having to deal with this lawsuit against the landlords from hell at the moment 19:55:08 * nickm nods 19:55:11 i think that's it 19:55:15 ok 19:55:20 tonight at ~9 then 19:55:24 (my time) 19:55:26 ~6 yours 19:55:31 cheers all 19:55:37 rl1987: can you end the meeting? 19:55:42 sure. 19:55:45 #endmeeting