Sprint planning meeting for sprint 2011-12-20

Date: 2011-12-06



Past Sprint Summary

Tickets closed: 12 :(
Est. of closed tickets: 37 :(
Tickets in review: 11
Est. of tickets in review: 29 (but not all of them have estimates)
Tickets left unassigned: 6

Excuses: time off for several people (which also means review tickets tend to linger longer since there are less people to pick them up), some new tickets based on external bug report (like #1442)

Jinmei: General impression is that this sprint is something like what we expected, considering most of the tickets are already in later stage of review and close to merge. Most of the others were taken, so there do not seem to be so many "really open" tickets remaining.

Shane: the idea here was to define requirements that did not come from protocol definitions

Jinmei: so what do these tickets mean in the context of the proposed queue?

Shane: we should probably ignore them for this meeting, we should probably discuss these on the dev list

Past Sprint Review


  • DDNS use-cases and design

(we did discuss basic design, and created tickets, both for user stories and detail design, and work)


  • Finish and use socket creator

Michal: Server part is done, but we need a small addition on the server side. However the client side is kind of in flux. C++ side will take some time. Don't really need on the Python side now (no daemons use this). When libraries are finished we need to switch auth server and resolver to use it.

Michal: Completion of API this sprint, switch the sprint after it.

Jinmei: Was goal really to finish?

Jelte: I think it was for the release...

Shane: Okay!

  • Start of finish NSEC3 support

(Tickets have been created)


Organizational Issues?

Any other comments?

What's happening to inactive tickets? (#1383 and #1386)

Jinmei: Sent a mail to -dev list - there are a couple of inactive tickets that were assigned to a developer but have no updates for more than a week.
Stephen: #1383, having been looking at it.
Jinmei: Takes time because of holidays?
Stephen: I'm really only working part time on BIND 10 DNS.
Jinmei: If too busy, we may want to reassign...
Stephen: This is just logging a FORMERR.

Jelte: Should Shane or me regularly check tickets and poke people?
Stephen: I think that would be a good idea.
Jinmei: I think we should review at the sprint planning meeting and if something seems to get stuck we should discuss the next step.
Jelte: The problem is that at a sprint meeting it is too late. Perhaps some intermediate process...

Jinmei: The other one is #1386. I wonder if we really need to solve it now since it's related to the resolver.
Dima: There is progress on that, I'm on the final stages. All the logic itself is there, and I can test it against Microsoft servers, but I want a proper unit test to test the functionality and that's what I'm working on at the moment.
Jinmei: Do you have any problem in doing this?
Jinmei: Use daily status room for this? bind10-daily-status@…

Michal: Another status of ticket would be nice... "waiting for dependency".
Shane: I think we can just create another status.
AP -> Shane will look at this.

Jinmei: I also noticed a couple of tickets that were not originally planned were pushed to the sprint were pushed to the sprint. Was there a reason for that?
Michal: I added 3, but they were splitting a ticket that was already there.
Jelte: I pushed one from a user report, since it would solve the problem.
Shane: I think in the past a ticket that just needs review could be pushed to the next sprint, unless urgent.
Jinmei: As long as we understand the basic idea and the reason was explained and we break that, that it's okay.

Next Sprint


  • DDNS
  • NSEC3
  • Socket creator (finish client API)

Tickets for next sprint

  • Tickets from current sprint move all forward?
    remove 803 and 804
    move on 1315 and 1317
  • Tickets for goals
  • DDNS These are all the tickets based on the mail discussion and based on user stories; we do not necessarily have to include them all
        Tickets from mail discussion:
        1447    DDNS design document    DDNS    6 
        1451    Create DDNS process module    DDNS    6 
        1452    add UDP socket passing to fd_X handling    DDNS    5 
        1454    Pass UPDATE packets from b10-auth to DDNS module    DDNS    3 
        1455    Add prerequisite checks to the DDNS module    DDNS    6 
        1456    Create diff-normalizer utility functions    DDNS    5 
        1457    use the difference normalizer in the DDNS module    DDNS    3 
        1458    ACL checks in DDNS module    DDNS    4 
        1459    Consistency checks in DDNS module    DDNS    5 
        1460    Define system-level tests for DDNS    DDNS    5 
        1461    Implement DDNS system tests    DDNS    7
        Tickets from user stories:
        1465    DDNS User Story: DDNS Analysis Tools    DDNS    0 
        1466    DDNS User Stories: No DDNS Option    DDNS    0 
        1473    DDNS User Stories: Finding inactive DDNS machines    DDNS    0 
        1474    DDNS User Stories: Make it fast    DDNS    0 
        1478    DDNS User Stories: Requirements for high volume    DDNS    0 
        1479    DDNS User Storie: Crash-safe journal    DDNS    0 
        1480    DDNS User Stories: Dynamic Updates to specific view    DDNS    0 

                Total: 55 (excluding the unestimated user story ones)

Shane: Dependencies?
Jelte: Most are dependent on the 1st two, or dependent on something else. For example #1454 depends on #1452, same for #1456 and #1457.
Jinmei: I think we will also notice missing things. So it does not have to be just 55. I can easily imagine we will find 10 points of additional tasks.

Jinmei: We can focus on DDNS and look at progress at the next sprint planning, then we can switch the focus to socket creator, which should be doable in a single sprint.
Michal: With the socket creator there is the unfinished task of the library, and everything depends on that, so if we do not finish it if there is not time for it. I also fear there may be some surprise on some systems for that.
Jelte: If you are already working on it, then you should finish it.
Jinmei: Our first priority is DDNS, and we can still do others at a lower priority.

Jelte: We can also do the 1st NSEC3 ticket in this sprint, and all the others go into DDNS, we can do that for instance.

Shane: So... #1431 from NSEC3, current socket creator ticket, and new feature tickets are DDNS.

Jeremy: we should do system tests early. (#1460, #1461)

So, we take:

#1447 6
#1451 6
#1456 5
#1452 5
#1460 5

Jelte: split up #1461? for example a way to update packets (could be nsupdate), and so on

#1455 6

DDNS points (so far): 33

  * NSEC3
        1431    NSEC3: closest provable encloser proof    NSEC3    6 
        1432    NSEC3: QNAME does not exist    NSEC3    4 
        1433    NSEC3: QTYPE does not exist    NSEC3    4 
        1434    NSEC3: wildcard match    NSEC3    5 
        1435    NSEC3: unsigned sub-zone    NSEC3    4 
        1436    NSEC3: validation of NSEC3 RRs in returned answer    NSEC3    4 
        1437    NSEC3: special cases    NSEC3    4 
        1438    NSEC3: consistent selection of NSEC3PARAM    NSEC3    5 

                Total: 36

Jinmei: We should hold off until we complete the data source refactoring. (#1198)

NSEC 3: #1431 6

  • Tickets from proposed

I'd like to see us address at least three tickets based on Francis' work;

        #903    'this' : used in base member initializer list        2 
        #911    time64 & Y2038        3 
        #1470    address trivial fixes from francis' mail        5 

                Total: 10 (though these were added later and had few estimations)

Jeremy: log output is interspersed
Michal: can we turn on line buffering?
Jelte: We can do this on #1405

#1462 3
#1369 2

Jelte: Should probably clear the difftable on forces AXFR-style IXFR, since it is possible to really confuse our difftable.

#1424 4
#1440 1
#1430 2
#1414 4

  • Statistics?


Next work is #1448.

  • Enough defects?
Last modified 7 years ago Last modified on Dec 6, 2011, 5:21:31 PM