Changes between Version 1 and Version 2 of RTeamSprintMinutes20101102

Nov 2, 2010, 4:00:41 PM (7 years ago)



  • RTeamSprintMinutes20101102

    v1 v2  
    8383Michal: Better if you can edit it at the time you are taking the task. If someone edits it, then two people can take the same task the same time.
     85Jelte: I think the whole XLS thing did not work.
     87Stephen: The advantage is I could put the estimates in and produce the chart. But I think you're right and the task list needs to be on the Wiki.
     89Stephen: If we can break our tasks down into sufficiently small tasks that a person can do a number of them during the sprint, then we will note the burndown by completed tasks. If the burndown is longer, then we have to ask the estimate for the amount of time remaining, and that is much more inaccurate.
     91Michal: Small tasks are better if we can make them. But some tasks are hard to split because you need to think about it and implementation goes along with it. If someone takes over in the middle it means a lot of overhead, and there is a dependency. Some tasks are naturally bigger than the small ones.
     93Stephen: I think what you're saying is that not all tasks will be interchangeable. I think what you're suggesting is that it is more efficient for one person to do all tasks sometimes.
     95Michal: If we split it into tasks, the splitting would be unnatural. You split the task in the middle, and you don't know the name of the split because there is no "real" way to split it. So you split in half and call one part A and one part B.
     97= Planning for next 2 weeks =
     99Stephen: Not a lot of us are going to be around. I'll be gone on Thursday, then to IETF. Jelte going Saturday. Likun & Ocean will be busy with the IETF. Fujiwara-san also attending? That leaves Michal, Aharen-san as normal time for next 2 weeks.
     101Stephen: Propose we do reviews and merges. #327 and #356 are main strands... how are we going to merge back together?
     103Michal: Suggest we do reviews, and then Aharen-san and me can merge these back into #327, then merge #327 into trunk. We won't be stopping anyone from work.
     105Jelte: That sounds like a good plan.
     107Stephen: There is also #356. I've done most of the stuff on that, but Ocean wants to start modifying code?
     109Ocean: Right.
     111Stephen: Only Ocean and myself working on that, I'm going to be flying Thursday and busy tomorrow, so maybe best for Ocean to continue to work on that branch.
     113Ocean: Okay.
     115Stephen: Shane produced a list of outstanding reviews (currently on spreadsheet!), we'll post that to Wiki and send a link around to it. I'll add to that the outstanding tasks on the current sprint, so all of that will go on the Wiki in the next few hours. If people assign themselves to tasks by editing the wiki, we'll track task assignments that way.
     117Stephen: Then we'll discuss what will form the basis for the sprint after that.
     119Larissa: Do we need to break down the existing tasks and reviews further?
     121Stephen: I think they might be okay. We won't have a lot of people around for the next couple of weeks. I am hoping the reviews and merging and other existing staff will be enough to occupy people who will be doing that work until we get to the next sprint planning session.
     123Jeremy: What about adding new tasks? Are we doing that today?
     125Stephen: Given the relatively few people who are going to be working, I was not planning on adding new tasks to the sprint. That will come at the planning session in 2 weeks time.
     127Jeremy: I misunderstood. I thought the one sprint was over, but we are beginning a new sprint now with only a few developers?
     129Larissa: Yes, but we will re-use tasks from the last sprint since we only have a few people.
     131Jelte: Yeah I'd like to do a few tasks that came out of the work for the last weeks.
     133Stephen: What sort of tasks?
     135Jelte: The work Michal did on the configuration of the recursor identified a few problems with the way configuration is handled and presented by bindctl. Ticket #384 about this. I have identified 3 smaller tasks within that. 1 is a couple hours, 2 are a little bigger.
     137Stephen: If they are only 2 or 3 hours, then I think we can put those in. I think what you've identified is a way to tie Trac with the task backlog. Regarding Trac as the task backlog is a useful idea. Titles need to be quite good in terms of description so we can cross reference them.
     139Larissa: In the feature backlog for BIND 9 we've rated things by priority and value, in Trac we have some of that but not all of it. I think if we can assign priority and severity in there, maybe we can figure out some process for working some of them into every sprint. And ones people want can have higher priority. We did that in BIND 9 and possibly that would be useful here.
     141Stephen: Since we'll put the list of tasks on the wiki if you can e-mail me the ticket numbers you think are important... if they potentially have impact on the A-Team work as well, if they will take a few hours...
     143Jelte: One is a few hours, the other two are 1 or 2 days...
     145Stephen: E-mail them!
     147Jeremy: I benchmarked #327 at the branch point and then also later. It had a 25% slowdown on queries per second. A very significant slowdown. Someone needs to spend some time re-evaluating it and tracking it down. It was in the auth server, but it was abstracted out in #327 in that code. We can either do it now or 6 months or a year from now! Just to point out the auth server dropped from 45k queries/sec to 2k queries/sec. Over time it has been a lot more. It is substantially getting slower and slower.
     149Jelte: Lot of allocations and freeing in every query right now.
     151Stephen: To me that is sounding as though we need to tackle this early on. Maybe get some custom allocators and deallocators written. Otherwise we'll have problems later on.
     153Michal: First solve memory leaks, then optimize allocations.
     155Jelte: I fixed all the memory leaks I could find.
     157Michal: I'm not saying speed is not important! But I am skeptical about including it in this sprint.
     159Jelte: Evan had some ideas about using "new" and pre-allocating data that is done within the event handling system. But that is not simply a one-day task.
     161Stephen: Does it have an impact on the longer term design? NSAS makes a lot of use of shared pointers. Has anyone done measurements on shared pointers? It could be shared pointers slows things down considerably.
     163Shane: There is a micro-benchmarking tool in the code base. Ask Jinmei for details.
     165Stephen: If we need to change the design we should find out early on.
     167Stephen: Shall we put performance on the sprint in 2 weeks time? There won't be people in the next 2 weeks.
     169Jeremy: Okay.
     171Stephen: Everybody happy with that?
     173[ general grumblings of approval ]
     175Stephen: Will get the tasks on the wiki today or early tomorrow.
     177Stephen: When should we start planning for the next sprint then? Maybe we should do the bulk by e-mail for the next sprint?
     179Jeremy: I think we have to.
     181Michal: By e-mail meaning dev-list or team-list?
     183Stephen: I was thinking team list. Doing discussion about project management could mean losing interest of people following the dev list. People are not really interested on work scheduling.
     185Larissa: Trick is to put technical discussion to dev-list and other stuff to team-list.
     187Shane: team-list is members only
     189Michal: Maybe we should make an admin list that is open for reading but not posting.
     191Shane: We could open the team list for reading only?
     193Jeremy: It does have some private-only stuff.
     195Larissa: I think the solution is technical meaty discussion to happen on bind10-dev and then put summaries of sprint reviews to bind10-team.
     197Jeremy: I think it is disjointed to pick & choose lists going back and forth. Readers are only getting half of the story. I don't think we have very many operation mails to bother readers on the dev list.
     199Shane: I'll ask the bind10-dev list readers what they think, and hopefully we'll get feedback before we do our e-mail planning next week.
     201Stephen: I'll put the lists of uncompleted tasks on the wiki.
     203Stephen: Anything else?
     205Michal: If I want some code from a branch that is not on the last sprint, is it okay to ask someone to review it?
     207Stephen: I would say "yes". If you need code from that branch and it needs review, it is okay to ask someone to review it.
     209Michal: Well... it's not necessarily needed, but there would be less work.
     211Shane: Makes sense.
     213Stephen: It should logically be part of the sprint.
     215Michal: It is a review of ticket #300.
     217Stephen: Ideally we should do estimates, but with only 2 people I don't think we need to for the coming sprint.
     219Jeremy: Decisions of not including changelog entries... I've noticed that a few times, and if we have noticeable behavior change, I think it should be noted in the changelog. Some things are said to be minor, but should still be noted.
     221Shane: Please send mail to the bind10-dev list? Thanks!
     223Michal: Also it is hard to know what should and should not go into the changelog, so if you could point out what should go in there...
     225Jeremy: Okay we'll discuss it elsewhere.
     227Stephen: Thanks you!