[bind10-dev] R-Team Sprint and Associated Estimates

[Stephen Morris]

R-Team Members

Following the R-Team meeting today, the task list for the sprint can be found at http://bind10.isc.org/wiki/RTeam20101130.  I've also updated the task backlog at http://bind10.isc.org/wiki/TaskBacklog

Concerning estimating, we left it that each of the R-team members would send me their estimate of each task.  (Please do not copy the email to the list - it may bias other people if they can see your figures.)  I will collate them and send the summary to the list.  Where the estimates diverge, I'll arrange another telephone conference where we can resolve the differences.

Please assign an estimate to each of the sprint tasks listed at the end of this email.  The estimate should be one of the following values:

1, 2, 3, 5, 8, 13, 21, >21 and ?  (? means "no clue")

When assigning values, compare the tasks with one another.  If you feel that task A will take twice as long as task B, assign it double the score of task B, rounding the score up to the nearest available value.  (So if you feel that task B should have a score of 3, then task A should be assigned a score of 8 - the next higher value above 2x3 = 6.)  As a guide, the first task has been assigned a value of "5".

Note that the review tasks which appear in the Wiki task list have not been included.  The reason for this is that the estimates should be indication of how long a task is likely to take, they are not an estimate of the length of the task in days.  If (and this is the assumption) the effort required of the ancillary tasks (such as reviews and documentation) is in direct proportion to the effort required of the task itself, the relative sizes of the tasks do not change when the associated work is taken into account.  When the sprint is complete, we can work out how many "estimate points" we can get through in any one sprint, which then guides us for the rest of the project. 

Two final things:
a) can only the person who is working on the task marked "<In progress>" below estimate for the remainder of that task?  As the rest of us are unlikely to know how complete that task is, the drawback of having one person estimate for it has to be balanced against a number of people estimating but without complete information.
b) The task list does not include the tasks for the bug backlog.  As soon as Jeremy has chosen the ones he would like us to tackle, I'll ask for those estimates in a separate email.

Stephen


Task List
=========
Refactoring: put in library for DNS services
Wxtracting common code from the authoritative and recursive servers into a common library. It was agreed though that this will only be done when all branches from ticket #327 have been merged back into that ticket and then the completed ticket merged back into trunk.
Estimate: 5

Merge tickets #393, #401 and #402 back into #327
These tickets are all branches off #327. They need to be merged back into it before the review can take place.
Estimate:

Review of All Tasks related to #327
This involves a broad review of the changes made to ticket #327 before it is merged back into trunk.
Estimate:

Merge #327 back into trunk
Estimate:

Demux: design phase 1
The Demux component is the component that matches incoming responses with outgoing queries. This is a task for Evan (if we can get him back from BIND-9 for a day) to write down initial thoughts on this.
Estimate:

Demux: design phase 2
Expanding Evan's thoughts into a more detailed design.
Estimate:

Ticket #408: General Control Logic/Logic to Handle NS and A Queries
This is the framework of the processing described in NameserverAddressStoreDesign, and includes the part that actually issues the queries and, when the queries return, updates the data structures and handles the post-processing.
<In progress>
Estimate:

Logic to update RTT
Definition of the data structures and processing required for the caller to update the RTT associated with nameserver addresses.
<In progress>
Estimate:

Address Selection Logic/RTT Banding
These tasks have been combined from the previous sprint. This concerns the logic needed to select the address with the lowest RTT, yet periodically try other addresses in case their RTT has dropped.
<In progress>
Estimate:

Add basic support for addressing individual list items
i.e. use [i] in a data structure identifier string to get to the i-th element (or something similar).
<In progress>
Estimate:

Fix bindctl printing of config data
Currently bindctl tries to be a bit smart (and not too well), and does not automatically print the contents of maps or lists unless you specifically ask for that map or list item. That property, combined with the current inability to address individual list items, makes it currently impossible to actually print out the contents of a list that contains maps. So it should be simpler: it should either print out 1 level of data (perhaps the default), or print the full JSON representation of whatever is there.
<In progress>
Estimate:

Recursor Cache: Requirements
Drawing up the requirements for the recursor cache.
Estimate: 

Recursor Cache: API Design
Design of the API into the cache.
Estimate: 

Recursor Cache: Test Code
Writing tests for the cache code.
Estimate: 

Outline design for Recursor processing logic
Produce a design for the processing (primarily based on section 7 of RFC 1035 but also including anything from other relevant RFCs). This does not include DNSSEC processing.
Estimate: 

Logging: Requirements
Drawing up the requirements for BIND-10 logging.
Estimate: 

Logging: API Design
API design for BIND-10 logging. Although it is likely that the logging will be implemented using an existing logging framework, a level of abstraction will make it easier to change the implementation if desired.
Estimate: 

Logging: Test Code
Writing tests for the logging code.
Estimate: