wiki:RTeamSprintMinutes20101214

Attendees

Stephen
Larissa
Jeremy
Shane
Scott
Likun
Michal
Jelte

Current Task List Review

https://bind10.isc.org/wiki/RTeam20101130

Stephen: Will be able to review estimates and completions and start to get a feel for our velocity.

Stephen: We have to think about breaking things down into bite-size chunks.

Jelte: Hear-hear.

Stephen: Branches from branches are a bad idea.

Shane: Never again!!!

Michal: #348 did not have this problem.

Stephen: Certainly #327 was a problem.

Jelte: Problem was that it took a long time to get sub-branches in and the trunk had changed. This is a general problem of long-lived branches.

Forthcoming Sprint

Discuss stories and features for forthcoming 2 weeks.

Shane: We need to deliver a working recursive server in Year 2. The focus should be on basic features - everything else can wait.

Stephen: I think we can drop refactoring from the next sprint. The #327 tasks need to be done.

Jeremy: I opened 6 or 8 tickets based on troubleshooting #327. I don't know if those need to be looked at first or if those can be looked at after #327 goes into trunk.

Jelte: I looked at the ones assigned to me and decided it would be better to get #327 back in first.

Jeremy: There just wasn't any feedback so I was curious!

Stephen: The demux... this is the bit that is a fundamental part of the recursor.

Stephen: bindctl printing of data... how far are you through Jelte?

Jelte: About half way. I think we should include this as a target because it is essential for use of recursive server.

Stephen: Recursive cache requirements complete. API design and test code is important and needs to be carried through.

Stephen: Logging requirements done. API design started. Reason is that the more code we do without logging the more code we will need to rework later. Is it worth diverting effort to do this now or should we wait until March/April?.

Michal: I think designing the API and providing something that is dummy logging (like print to stdout)... isn't that much work?

Stephen: I thought the implementation wouldn't be that much work, since it would be based on something like the Apache log4cxx.

Shane: If it's not that much work then we should go ahead. It will be very helpful for administrators.

Stephen: 5 bugs were there because we needed to make an impact on the backlog of bugs. Should we pull bugs forward and include in every sprint?

Jelte: I think it is a good idea.

Michal: 7 bugs regarding cursor... we can postpone the decision until next sprint?

Stephen: My thought is that it's useful to have some of these bugs in, if only because some of them are very small tasks.

Stephen: [ breakdown of tasks ]


ACL needed?

Shane: probably not yet


TSIG needed?

Jeremy: For the recursor side, not yet.

Stephen: Done on the authority side?

Shane: Added to libdns++ but not included in any of the protocol-level pieces, like xfrin or xfrout


Cache needed?

Michal: We can do something like std::map as a first pass to make sure the API works.

Stephen: I agree. The first version only needs functionality and does not need to be fast. It might save us a huge amount of time.

Michal: I was going to propose putting the implementation into the same task as the tests. I usually write the test then the code.

Stephen: I think Michal is right. You write the test, make sure the test fails, then write the code.

Shane: I agree with Michal's proposal.


NSAS ready?

Michael: More-or-less usuable. 4 or 5 TODO items, but those can wait.


Pseudo-random number generator?

Stephen: Ocean has used the pseudo-random number generator in Boost. I can't help feeling using something in Boost is the way forward.

Michal: I looked at the way Boost has random number generators and there are like 10 or 20 to choose from and layers on top of it to transform them. The hard part is not using them but deciding which to use.

Stephen: We have a pseudo-random number generator.

Michal: We have a lot. They are all pseudo-random but unless we need it to be cryptographically safe they are okay.

Shane: We kind of do need for them to be cryptographically safe, because we are trying to protect against people predicting our random numbers.

Stephen: I think this is okay for our immediate need for getting the recursor ready by March. We can have a look at the Boost random number generators to make sure they are cryptographically safe, and make it a task in the backlog for year 3.


Validating signed data?

Stephen: We were thinking about not starting until the January meeting.

Shane explains that it's okay to wait until then.

Jeremy: At one point we mentioned keeping stubs for that. So, tracking DNSSEC keys but not doing validation.

Stephen: We said we would put some DNSSEC at the end of year 2. I don't know how easy it is to bolt on DNSSEC onto the recursive logic if we write it without it.

Shane: Was BIND 9 done with DNSSEC already spec'd?

Jeremy: Yes - the old DNSSEC.

Stephen: My feeling is we should focus on the validating resolver first before we start thinking about DNSSEC. It will be much better if we say "we have a working resolver, we have not quite finished DNSSEC" than "we have nothing working but we almost have a validating resolver working".

Jelte: I'm not sure. I'm not sure how it would appear if we come out with a resolver that does not do DNSSEC.

Stephen: I think it would be better than a resolver that does neither resolving nor DNSSEC. We talked about deferring DNSSEC until the meeting in January, and as Shane says we'll have plenty of work for the next 4 weeks, so it is something we can defer until January.

Jeremy: As for now, it seems like if the incoming query has the DO bit we should pass that through - for the forwarder. So at least we should get the information.

Jelte: That is one big difference between a validating resolver. It's not only the checking, but also a validated cache and the dirty cache.

Stephen: That needs feeding into the cache design.

Stephen: DNSSEC will be at our meeting in January, so it will be a topic of conversation?

Shane: At least one day.


ASIO

Sorted!


dispatch / demux

Stephen: Would that form a more-or-less complete set of components for the recursor?

Shane: I think so. That was my hope at least.

Task List for next Sprint

Carrying through demux.

Stephen: Scrum means team decides among themselves.

Michal: About the cache... do we have the requirements? Can we split into multiple tasks, or do we have to wait until the API design? Can we split for multiple people? If we have one huge task then.

Shane mentions a way to split into tasks.

Michal: But doesn't help multiple people working on the task.

[ Stephen edits text in real-time ]

Next step: Tasks put on Wiki, then e-mail asking for estimate and results back to Stephen.

Last modified 7 years ago Last modified on Dec 14, 2010, 4:25:23 PM