BIND 10 #2004: Message_makeResponse (libdns++ python wrapper) should catch exceptions

[BIND 10 Development]

#2004: Message_makeResponse (libdns++ python wrapper) should catch exceptions
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  assigned
                       Type:         |             Milestone:
  defect                             |  Sprint-20120612
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  libdns++                           |  Estimated Difficulty:  4
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:4 muks]:

 > > Could you first complete the things you are currently working on?  Or,
 if you get stuck
 > > with the existing ones with difficulty, could you release it and ask
 someone else for
 > > taking over it?
 >
 > I am working on my tickets (as you can see from commit logs and ticket
 updates). One ticket takes time to do a full check each time, and for
 another I am reading before I can fix it. So it's best if I put another
 ticket that I _can_ fix to review before I do that so that in a week, i
 would have fixed some things.

 I understand it for the longer check one, but starting another ticket
 while you're "reading" (not sure what you mean by this though -
 something like reading RFCs or something to understand the issue
 better?) doesn't make much sense to me.  If you need to read for some
 ticket, I'd suggest completing the reading first, finishing the
 corresponding ticket, and then starting a new one; or if you think the
 reading could take too long, release the ticket so that someone else
 (who has possibly sufficient background to take over it without doing
 extra reading) can complete it.

 The point is that, if one starts doing a new task while leaving
 something that same person owns in the review queue, we'll build a
 longer backlog in the queue.  In general, we try to keep it short,
 and, basically, we expect one developer normally owns at most two
 tickets, and normally at least one of them is a reviewing task.  A
 single developer owns four tickets, all as a developer, is quite
 unusual.

 Also, owning a ticket effectively works as a lock, preventing others
 from working on it.  So, even if some other developer owns nothing and
 can work on a new task exclusively, the locked task cannot be owned.
 Consider an extreme case where one developer owns all tickets, pending
 everything while "reading" something for them.  Then the rest of the
 developers cannot do anything unless the "reading" developer unlocks
 some of the tickets.

 Of course, under specific circumstances it might be possible that the
 best choice is for one developer to own 3 or more tickets at the same
 time.  But at least to me, the current status where you owned
 #1704/#1771/#1828 and started a new one is something quite different
 from what we generally expect.

 > I also don't have more than 1 ticket in 'assigned' at any time (except
 once when I had already finished a ticket and was waiting for check to
 finish).

 In my understanding, "accepted" or "assigned" doesn't mean anything to
 us beyond that the ticket is owned by that person (we have these
 simply because trac has them).  What matters is who owns which ticket,
 and how many tickets a single developer owns at one time.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2004#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development