Changes between Version 1 and Version 2 of RTeamSprintMinutes20101102


Ignore:
Timestamp:
Nov 2, 2010, 4:00:41 PM (7 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RTeamSprintMinutes20101102

    v1 v2  
    8282
    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.
     84
     85Jelte: I think the whole XLS thing did not work.
     86
     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.
     88
     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.
     90
     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.
     92
     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.
     94
     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.
     96
     97= Planning for next 2 weeks =
     98
     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.
     100
     101Stephen: Propose we do reviews and merges. #327 and #356 are main strands... how are we going to merge back together?
     102
     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.
     104
     105Jelte: That sounds like a good plan.
     106
     107Stephen: There is also #356. I've done most of the stuff on that, but Ocean wants to start modifying code?
     108
     109Ocean: Right.
     110
     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.
     112
     113Ocean: Okay.
     114
     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.
     116
     117Stephen: Then we'll discuss what will form the basis for the sprint after that.
     118
     119Larissa: Do we need to break down the existing tasks and reviews further?
     120
     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.
     122
     123Jeremy: What about adding new tasks? Are we doing that today?
     124
     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.
     126
     127Jeremy: I misunderstood. I thought the one sprint was over, but we are beginning a new sprint now with only a few developers?
     128
     129Larissa: Yes, but we will re-use tasks from the last sprint since we only have a few people.
     130
     131Jelte: Yeah I'd like to do a few tasks that came out of the work for the last weeks.
     132
     133Stephen: What sort of tasks?
     134
     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.
     136
     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.
     138
     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.
     140
     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...
     142
     143Jelte: One is a few hours, the other two are 1 or 2 days...
     144
     145Stephen: E-mail them!
     146
     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.
     148
     149Jelte: Lot of allocations and freeing in every query right now.
     150
     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.
     152
     153Michal: First solve memory leaks, then optimize allocations.
     154
     155Jelte: I fixed all the memory leaks I could find.
     156
     157Michal: I'm not saying speed is not important! But I am skeptical about including it in this sprint.
     158
     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.
     160
     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.
     162
     163Shane: There is a micro-benchmarking tool in the code base. Ask Jinmei for details.
     164
     165Stephen: If we need to change the design we should find out early on.
     166
     167Stephen: Shall we put performance on the sprint in 2 weeks time? There won't be people in the next 2 weeks.
     168
     169Jeremy: Okay.
     170
     171Stephen: Everybody happy with that?
     172
     173[ general grumblings of approval ]
     174
     175Stephen: Will get the tasks on the wiki today or early tomorrow.
     176
     177Stephen: When should we start planning for the next sprint then? Maybe we should do the bulk by e-mail for the next sprint?
     178
     179Jeremy: I think we have to.
     180
     181Michal: By e-mail meaning dev-list or team-list?
     182
     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.
     184
     185Larissa: Trick is to put technical discussion to dev-list and other stuff to team-list.
     186
     187Shane: team-list is members only
     188
     189Michal: Maybe we should make an admin list that is open for reading but not posting.
     190
     191Shane: We could open the team list for reading only?
     192
     193Jeremy: It does have some private-only stuff.
     194
     195Larissa: I think the solution is technical meaty discussion to happen on bind10-dev and then put summaries of sprint reviews to bind10-team.
     196
     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.
     198
     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.
     200
     201Stephen: I'll put the lists of uncompleted tasks on the wiki.
     202
     203Stephen: Anything else?
     204
     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?
     206
     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.
     208
     209Michal: Well... it's not necessarily needed, but there would be less work.
     210
     211Shane: Makes sense.
     212
     213Stephen: It should logically be part of the sprint.
     214
     215Michal: It is a review of ticket #300.
     216
     217Stephen: Ideally we should do estimates, but with only 2 people I don't think we need to for the coming sprint.
     218
     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.
     220
     221Shane: Please send mail to the bind10-dev list? Thanks!
     222
     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...
     224
     225Jeremy: Okay we'll discuss it elsewhere.
     226
     227Stephen: Thanks you!