wiki:RTeamSprintMinutes20110125

Attendees:

Stephen
Jelte
Jeremy
Likun
Ocean
Scott
Shane
Larissa

Stephen: How have things gone? Major problems?

Scott: I think we have sorted things out, although right now there is a unit test problem on master.

Stephen: How do people feel about the change to using timeline on the milestone page? Was that useful?

Jelte: I love it.

Scott: That's really great. Easy to search for specific things you are looking for.

Stephen: We completed 19 estimate points in this last sprint.

Jelte: Actually more because I'm about to merge Scott's stuff...

Stephen: The problem is the sprint finished 2 minutes ago!

Scott: I just found the problem in #484 too!

Stephen: Will make "milestone complete" and move tasks over to next sprint for record keeping.

Stephen: Do people still think we will have a working resolver by the end of the year?

Scott: I may be too optimistic, but it seems like it to me.

Jelte: Same disclaimer, same conclusion.


http://bind10.isc.org/query?milestone=R-Team-Sprint-20110125&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=resolution&col=estimatedhours&order=priority

Stephen: 19 points per sprint, 91 (slightly less) left.

Shane: Using "estimated hours" even though that's not actually hours.

Stephen: In reviewing, we have 22 points. In the end of 6 weeks we should just about have completed things.

Shane: Chinese new year is coming up...

Stephen: So we'll be flying a bit tight. So we want to restrict ourselves to tasks necessary to complete the resolver.

Stephen: Added "refactor resolver ASIO interface". Is that necessary as part of this sprint?

Jelte: I think some of it is necessary. For example encapsulate for the demux, or the thing that the cache can ask the resolver to do some resolving. But perhaps we can do these as part of other tasks?

Scott: That my be okay if we agree to make it a very high priority to put together a design and refactor after the new year starts. The problem is that - looking at some of the code - there are clearly areas where we are very inefficient in the way we do things.

Jelte: Yes.

Scott: A cleaner interface would take care of all of that.

Stephen: I think the thing there is the terms of actually defining it. If we're going to refactor it we should step back and think about it and move to that design. The thing I am more concerned about is, "is this something that should be done betweeen now and the end of year 2, or something we can tackle in year 3".

Scott: I think if we step back and design it now we won't have enough time to bring a working resolver at the end of the year.

Jelte: I agree. Some small refactors will be necessary anyway...

Stephen: I agree.

Jelte: If we start the design work now we can put off the big refactor until next year.

Stephen: Refactoring will be put off until year 3, but we should think about the design now. Should that be a separate task or adding notes in passing?

Scott: I think it should be a separate task, and it should be started in Trac now. Then we can do what you just suggested, where we don't actively work on it, but as things arise we can make notes, and it can act as a placeholder.

Jelte: The final finishing would be to take all those notes and add it to the document and make a document out of it?

Stephen: Best to do this as a conversation on bind10-dev?

Scott: The Trac system is different from how I have done in the past. Maybe this is not the best way to go about it. At some point we can move the bind10-dev into Trac...

Jelte: I can try making a Wiki page...

Stephen: We do have that. One of the pages is "resolver". There is a design....

Jelte: The steps to implement, which we base our current task list off of.

Stephen: We could add "resolver refactor notes" page. Then when we do the refactoring someone will write a design page.

Scott: I think that's a good way to go. I like it better than bind10-dev.

Stephen: I'll create a page for the refactor.

Scott: Did you use dia for the diagram?

Jelte: I used Inkscape. I'll put up the SVG file.

Stephen: We have the milestones for the sprints, and "feature backlog", and a bunch of tasks not related to anything. The task Jelte created probably belongs on the R-Team task backlog. I had put a task into the general backlog. Is it worth making an explicit R-Team task backlog milestone?

Scott: Sounds helpful to me. If I create something that crosses the boundaries, what then?

Stephen: We'd probably put it on the task backlog and then have a discussion about that at a planning meeting.

[ discussion about backlogs... agreement to create "R-Team task

backlog" ]


Stephen: Tasks for remainder of this sprint. Any thoughts on upcoming tasks?

Scott: I think it is hard to say. I think the way we estimate tasks is a little bit arbitrary. For example the root IP addresses was a 2 and the work Jelte did was a 5, mine took 2 days Jelte's took 10, so I don't know if that is a useful thing to measure.

Stephen: Estimating is the hardest part of any project!

Stephen: It will be interesting to see how much we get through in the coming 10 days and see if the velocity is the same or wildly different or what. I don't see any other way around it.

Scott: I think in 3 or 4 months we'll have much better estimates.


Stephen: Anything else anybody wants to raise? Although this is a planning meeting we have done most of the planning a few weeks ago...

Jelte: I have one more task we will want to cover. The defaults are not correctly read out of the configuration module.

Likun: So can we change the default value in the spec file to make it match the code.

Jelte: I think maybe a 3 or a 2 for this...


Shane: Likun, can you or someone e-mail the exact dates of the Chinese new year.

Likun: Okay.


Stephen: There was great value in the face to face, so we will try to do this at the next face to face.

Jelte: Sounds like a good idea.

Scott: I tend to agree.

Last modified 7 years ago Last modified on Jan 25, 2011, 4:29:11 PM