=== fenris_ is now known as e-jat === salgado is now known as salgado-brb === salgado-brb is now known as salgado [15:00] #startmeeting [15:00] * barry sighs [15:00] me [15:00] hello everyone and welcome to this week's ameu reviewers meeting. who's here today? [15:00] i [15:00] you [15:00] me [15:01] barry: gmb and allenap are on leave, BjornT is sprinting [15:01] intellectronica: thanks for the update [15:01] salgado, sinzui ping [15:02] me [15:02] me [15:02] EdwinGrubbs: ping [15:02] danilo_: ping [15:02] me [15:02] me [15:02] cprov: ping [15:02] me === danilo_ is now known as danilos [15:02] * sinzui was getting coffee [15:02] barry: I'm here ;) [15:02] cprov: :) [15:02] == Agenda == [15:02] * Roll call [15:02] * Next meeting [15:02] * Action items [15:02] * Queue status [15:03] * Mentoring update [15:03] * Review process [15:03] * watch for dead end links ([[https://bugs.edge.launchpad.net/launchpad/+bug/254436|bug 254436]] - flacoste) [15:03] Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete] [15:03] Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete] https://launchpad.net/bugs/254436 [15:03] * watch out for config or other changes w/ possible operational effects [15:03] * ideas for encouraging branches which cleanup/reduce tech debt [15:03] week += 1? if you know you won't be here, please update the wiki page [15:03] * barry thanks allenap for sending his apologies [15:03] i won't be here [15:04] intellectronica: cool, thanks [15:04] [TOPIC] action items [15:04] * abentley to update UsingMergeProposals with the extra approval step [15:04] I believe I did that. [15:05] abentley: cool, thanks [15:05] [TOPIC] queue status [15:05] nothin' much from me on this. does anybody have any comments here? [15:06] well, I broke the pending-reviews page for everybody on Friday [15:06] how? [15:06] so, it didn't get updated until yesterday [15:06] oh noes! [15:06] * sinzui noted it did not update for 48 hours [15:06] danilos: how did you do that? [15:06] (just so we know what not to do) [15:07] I did a "bzr upgrade" on my repo, it apparently didn't finish, and left my repo in a limbo state; I haven't noticed it broke anything until it was too late (rm -rf backup.bzr) [15:07] intellectronica: ^^ [15:07] so, I moved all of my branches out of the way in PendingReviews for it to start working again [15:07] abentley: what's the current state of mars's remove-structural-objects-ui branch? are you waiting on me? [15:08] * barry notices it has 8 conflicts now [15:08] barry: I thought mars was the next person to take action. [15:09] that's what I thought as well [15:09] abentley: it's still in needs-review state so if it's merge-*, just update PendingReviews [15:10] * barry issues another plea to remove branch summaries from PR when they've landed [15:10] barry: okay [15:10] [TOPIC] mentoring update [15:11] i just wanted to mention that we have slots open, so if anybody has a reviewer nominee in mind, please let me know [15:12] [TOPIC] review process [15:12] flacoste isn't here so we'll carry his forward [15:12] * watch out for config or other changes w/ possible operational effects [15:13] did anybody not catch the recent thread on config file changes breaking operations? [15:14] On a related note, I should have ask for rsync to pull the oops reports from xmlrpc-private. [15:14] cool, i guess everyone saw it. so when you're reviewing just keep an eye out for changes (such as to configs, scripts, etc) that the LOSAs might need to be aware of, and please point that out in your reviews [15:15] * ideas for encouraging branches which cleanup/reduce tech debt [15:15] i don't think we should encourage them [15:15] intellectronica: go ahead [15:16] tbh, i really don't like it when we mix new developments with cleanups. it makes reviewing harder [15:16] intellectronica: do you mean drive-bys or separate cleanup-only branches? [15:16] i much rather review a branch which /only/ cleans up, in addition to a branch which introduces new work [15:16] barry: i mean drive-bys [15:17] I like to clean up technical-debt in a preliminary branch that setup up my next branch. [15:17] individual branches with cleanups are great, of course [15:17] intellectronica: cool. this btw is in reference to joey's push for reducing our tech debt [15:17] sinzui: that's a good idea [15:17] intellectronica: so let's concentrate on cleanup-only branches [15:18] i'd love to have your thoughts on how we can do more cleanup-only branches [15:18] why do we tend not to do them? [15:19] i think one thing we can do it, is that if in a review we notice something that we think should be cleaned up, insist on opening a bug, and following up on it (making sure that it's at the very least scheduled, if not completed immidiately after the original branch) [15:19] can't we list related XXX in `make lint` ? that would encourage 'drive-by-cleanups', no ? [15:19] barry: I would think it's because we tend to encounter cleanup opportunities in the course of new development. [15:20] And starting a new branch for the cleanup feels like a lot of overhead. [15:20] cprov: that can be annoying, like that sample data experiment [15:20] looms reduce that overhead, of course. [15:20] intellectronica: very often i'll ask to open a bug for a deferred cleanup, but we don't seem to get around to it [15:20] abentley: overhead? starting new branches is cheap as chips [15:20] well, 'encourage' in that context would be more like 'force' and that might become hard to handle in content-class changes, for instance. [15:20] abentley: i think that's a good observation. maybe looms is one technique for reducing that overhead [15:21] as you point out [15:21] intellectronica: I'm not talking about IO time. [15:21] I'm talking about effort. [15:21] lint could report XXX, but I'm not sure that helps up to know when we have an opportunity to remove an XX [15:22] Now you're working on two branches instead of one, and you have to get both reviewed and merged.. [15:22] sinzui: that's true, XXX related with the fix might be in a untouched file. [15:22] abentley: looms solve the problem for you locally, then you can export separate branches from them for reviewing [15:22] * sinzui should put the XXX report into Makefile so that we can easily where they are and how they releate. [15:22] intellectronica: I know, because I wrote the export functionality. [15:23] :) [15:23] [ACTION] sinzui should put the XXX report into Makefile so that we can easily where they are and how they releate. [15:23] I guess I can work on my porn branch today [15:23] sinzui: rs=barry [15:24] does anybody think that we're so feature-driven that you don't have time to do the cleanup branches you want to do? [15:24] barry: I think we *were* when I joined. [15:24] (January) [15:24] abentley: but no more? [15:25] A pre-imp call is the best time to discuss closing XXX's [15:25] barry: No impending major release hanging over our heads now. Feels like there's some breathing room. [15:26] abentley: i ask because in foundations, we're planning 20% of our coding time for 2.1.9 to reducing the tech debt [15:26] i'm curious if other teams are doing the same? [15:27] barry: Code team's big focus is scalability. We must become scalable before we run out of disk space in October or so. [15:28] what do people think about an lp tag 'cleanup' so we can easily find the bugs related to cleanups? [15:28] I don't think we're working on a 20% rule per se, but cleanups (authserver => internal xmlrpc) are happening now. [15:29] abentley: thx [15:29] barry: i don't know if that's a very good name, but +1 for having a tag [15:29] cleanup can mean so many things [15:29] maybe 'tech-debt'? [15:29] intellectronica: i'll email the list for better suggestions :) [15:29] anyway, we can discuss on the list [15:30] let me also invite you to email me or irc/skype if you have any thoughts on changes to our process that would allow us to regularly pay down this debt [15:30] maybe we should also propose some ritual way of following up on cleanup opportunities that came up in reviews [15:30] i'm /very/ keen on doing this before we go open source [15:31] intellectronica: any thoughts on how that would work? [15:31] for example, a weekly report on cleanup actions from each team [15:32] intellectronica: maybe in the general lp meeting? [15:32] maybe, although, that would encourage /short/ reports [15:34] barry: jtv and myself have planned to do cleanup sprints, but that has probably been discussed already [15:34] danilos: yes, i think those are really good ideas, especially for big ticket items [15:34] like tree reorg and such [15:35] another (leading) question: does anybody feel that some kind of reward system would help, hurt, or be neutral in getting cleanups done? [15:35] barry: right, but you can also do much more easy cleanups when you don't have to worry about being constantly available, and when you have the entire team next to you [15:35] danilos: high bandwidth pair-programming and insta-reviews [15:36] barry: indeed :) [15:36] barry: what about bringing back Fix it Friday for tech-debt issues? === nand_ is now known as nand [15:37] bac: i like that idea [15:37] I think we need to introduce Darma, We need to do our job of closing technical debt to earn it [15:37] [ACTION] barry will propose a new bug tag for paying down tech debt [15:38] barry: I'm worried about productivity loss. Already, I'm only coding 4 days out of 5. [15:38] bac: although i never took part in it (it was stopped just after i joined) i must say that i find the segregation to one week-day to be a bit strange. did you have a good impression from that while it was on? [15:39] abentley: of course, you would still be coding, but just not on a specific feature [15:39] abentley: that is the downside of being a reviewer. [15:39] abentley: but i get what you're saying [15:39] abentley: I agree that each developer needs the power to say no so that he can focus on code. [15:39] although remember, it's total team throughput that we want to measure [15:39] intellectronica: i did have some good experiences. the aspect that it is a single day is odd, but the idea that the team would encourage clean-up activity was rewarding. [15:40] and don't cleanup branches feel GOOD? :) [15:40] intellectronica: we could do something similar. let a dev pick his day. [15:40] massive deletes are very cathartic. [15:40] bac: kind of like on-call [15:40] barry: Yeah, but I can choose to do cleanup any time. [15:40] barry: sure, but not so formal, i'd think [15:40] This would actually discourage me from doing cleanup except on fridays. [15:41] * barry nods [15:41] abentley: it's just a gimick, but perhaps a useful one. individuals can choose to manage their time however they and their team wants. [15:42] I think the right way to do this is to ensure team leads give tech debt a high priority. Then they can make sure their team gives it enough focus. [15:42] abentley: i agree with that. and i was gratified to see the time blocked out on the foundations schedule. [15:43] we're running out of time, so let me wrap this up for today. i really want to thank everyone for their ideas. i'll continue the discussion on the ml, so please do keep thinking about it [15:44] quick note: People may have noticed that review-submit is generating out-of-date MoinMoin markup. I have a branch in the queue to fix that. [15:44] in the last 2 minutes, does anybody have any other topics not on the agenda? [15:44] abentley: excellent, thanks [15:45] okay, that's it then [15:45] #endmeeting [15:45] thanks very much everybody! [15:45] thanks barry [15:45] we will give tech debt a high priority :-) [15:45] thanks barry. [15:45] Rinchen ! [15:46] working rule of thumb is about 20% of the cycle [15:46] Rinchen: -> #lp-code? === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado === salgado is now known as salgado-afk