19:01:01 <rl1987> #startmeeting
19:01:01 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:07 * dgoulet not far as usual :)
19:01:16 <nickm> hi dgoulet
19:01:35 <nickm> So, we have a big release out.  As soon as somebody can update the website, I'll announce.  That's good
19:01:41 <GeKo> mikeperry: and yes, UBSan issues are only logged and not fatal
19:01:47 * GeKo shuts up now.
19:02:09 <nickm> 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 <nickm> I think I should fork maint-0.2.5 and make master into Tor 0.2.6.  Agree?
19:05:49 <nickm> Assuming the answer is "yes".
19:06:08 <nickm> #agreed I should make Tor 0.2.6 development start now
19:06:14 <nickm> #idea or maybe it should be Tor 2.6
19:06:34 <rl1987> I th
19:06:48 <rl1987> I think 0.2.6 is more consistent with curent versioning scheme
19:06:51 <nickm> I've been thinking about the "what happened with 0.2.5" question
19:07:09 <athena> yeah, think it's time for 0.2.6
19:07:19 <nickm> on the one hand, since we did patch-freeze on 0.2.5, it's converged to goodness pretty well.
19:07:30 <nickm> on the other hand, it took a while longer than I expected.
19:08:03 <nickm> Part of me says that the answer is to prioritize patch review,.
19:08:20 <nickm> or maybe the answer is to declare a timeline for patch freeze more rigorously.
19:08:27 <nickm> or to defer more aggressively
19:08:37 <nickm> or something else.
19:09:23 <nickm> 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 <nickm> Assuming we want stable by december, do we need to declare patch freeze in september?
19:10:11 <nickm> that wouldn't be enough time to implement all the stuff I want to do this year
19:10:30 <nickm> otoh, if I plan to spend now through oct or nov implementing, I can't really try to stablize for dec.
19:10:47 <nickm> athena: do you think it's more reasonable to start with deadlines, feature lists, or what?
19:10:50 <nickm> others too
19:11:47 <wfn> how 'independent' is core t-tor development from particular funder deliverables? (vague question is vague, but on topic)
19:12:38 <nickm> 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 <athena> hmm, features always take longer than one thinks they will
19:13:13 <athena> if we want less schedule slippage, perhaps a more rigorous freeze deadline is the right approach
19:14:31 <nickm> 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 <nickm> 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 <nickm> or something else
19:15:09 <nickm> how could we find out?
19:17:11 <nickm> I ask because the responses are different in those cases
19:17:30 <nickm> 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 <nickm> 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 <rl1987> can we do some data analysis on trac tickets to have a broad view of what was going on?
19:19:14 <nickm> I like that idea but I am not too sure of what to analyze
19:19:17 <wfn> trac timeline should yield enough info to answer those particular questions, no?
19:19:20 <nickm> any thoughts there?
19:19:38 <nickm> rl1987: Is that something you'd like to explore?
19:20:03 <rl1987> I might look into this
19:20:11 <wfn> if the keyword 'triaged' conveys enough info ('this is merge-ready', whatnot), maybe it would be possible
19:21:20 <rl1987> is there an REST API in trac?
19:21:40 <wfn> (i assume not, but trac timeline is available for nasty harvesting, i think)
19:21:43 <nickm> 025-triaged means "we looked at this for 0.2.5 and didn't decide not to include it"
19:22:03 <nickm> 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 <nickm> I guess we could try to adopt _all teh solutions_
19:25:26 <wfn> (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 <nickm> 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 <nickm> not sure if that is sane
19:27:15 <meejah> karsten: sorry i missed tor-weather :( miscommuncation w/ my wife, and I had no computer to send mail/irc
19:28:14 <meejah> i will review lucyd's branch
19:29:29 <wfn> 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 <wfn> 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 <velope> 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 <nickm> yeah
19:30:50 <velope> for difficult bugs, get diagnostic patches in point releases earlier in cycle
19:30:52 <nickm> maybe we should triage early, not late
19:31:15 <nickm> athena: should we plan a triage time?  we have historically done that much better when working at the same time
19:33:52 <athena> nickm: yeah, probably
19:33:59 <nickm> ok. when's good for you?
19:34:05 <nickm> I am unexpectedly free after this meeting.
19:34:18 <nickm> and free at 2100 EDT plus epsilon
19:35:02 <nickm> others are welcome to join in too
19:37:14 <nickm> rl1987, wfn: Are you interested in trying to figure out how well 0.2.5 went (or didn't go?)
19:37:44 <nickm> (from a science POV, I maybe shouldn't be the person seeing how well we did)
19:38:24 <rl1987> yes, I will try to do some data analysis
19:38:28 <nickm> cool
19:38:43 <rl1987> what are the main questions to ask here?
19:38:47 <wfn> 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 <nickm> "results soon" is probably better than "better results later"
19:38:54 <wfn> i'll ping rl1987 when appropriate
19:38:59 <athena> 2100EDT is good for me i think
19:39:34 <nickm> 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 <nickm> athena: what questions do you want answered?
19:39:53 <rl1987> wfn: what about next week? I will be AFK this weekend.
19:40:27 <athena> were we bottlenecked on reviews or on bug fixes we committed to do in 025?
19:40:48 <wfn> 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 <nickm> of the stuff we triaged into 025, were we too ambitious?
19:41:05 <rl1987> I found that tickets can be downloaded in CSV format, yay
19:41:29 <rl1987> when did we declare path freeze?
19:41:50 <wfn> (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 <nickm> 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 <wfn> yeah. this would be a very science-y conclusion indeed
19:44:08 <rl1987> #action will be working with wfn to figure out why it took so long to reach stable release after patch freeze.
19:44:12 <nickm> also practical, since it would tell us what we need to record next time
19:44:29 <nickm> I believe that the patch freeze was shortly after the last dev meeting.
19:44:34 <nickm> athena: does that match your recollection?
19:45:05 <wfn> 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 <rl1987> does patch freeze mean "no new patches will be accepted"?
19:45:56 <rl1987> wfn: allright, will see what I can do myself
19:46:15 <nickm> 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 <nickm> I think
19:46:59 <nickm> See "New conventions for Tor ticket milestones" in tor-dev on feb 28
19:48:26 <athena> yeah, i think we patch-froze in march IIRC
19:48:46 <nickm> #action nickm and athena will triage 0.2.6 tickets tonight around 2100 eastern, plus epsilon
19:49:49 <nickm> 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 <nickm> one thing:
19:50:54 <nickm> 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 <nickm> *concluded
19:54:01 <athena> not yet; i keep meaning to rebase the scheduler against current master and have another read through it
19:54:41 <nickm> any smaller things of yours pending, or is that the only one?
19:54:44 <athena> 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 <athena> i think that's it
19:55:15 <nickm> ok
19:55:20 <nickm> tonight at ~9 then
19:55:24 <nickm> (my time)
19:55:26 <nickm> ~6 yours
19:55:31 <nickm> cheers all
19:55:37 <nickm> rl1987: can you end the meeting?
19:55:42 <rl1987> sure.
19:55:45 <rl1987> #endmeeting