[bind10-dev] [sprint planning] estimate results 20111206

[JINMEI Tatuya / 神明達哉]

At Tue, 29 Nov 2011 10:11:44 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > I personally believe that the current style of if-else analysis tends
> > to cause subtle bugs in boundary conditions and still personally
> > believe it's worth generalizing.  But at the same time I admit that
> > this may be a matter of preference and that the current code is not
> > particularly unreadable.  So, in the sense of avoiding
> > over/premature-generalization I'm okay with not doing this task.
> 
> OK, so let's wait until we find a bug there and see if it would be better fixed
> if it was split into classes. If so, then can we refactor it as part of the fix?

Yes, that's fine.  I've already canceled #1398 by closing it with
"wontfix".

> > At the very least, the traceback isn't helpful as a hint to solve the
> > problem (*I* know many details of the BIND 10 system and could figure
> > what was missing from the output, but *they* wouldn't).
> > 
> > So I'd keep this ticket as a task to find a reasonable middleground.
> 
> Would a correct exception and description be the middleground or do we need
> something else?

A correct exception and description could be a middle ground.
Personally, my preferences are:

1. some way to ensure it will be explicitly signaled if our internal
   program forgets necessary logging initialization, while allowing
   others to skip it when logging is not necessary.  I don't know the
   feasibility of this option, but I don't want to drop the goal from
   the beginning.
2. require logging setup for everyone but improve the error message
   (whether it's from exception or something else) so that it's more
   helpful to detect what's missing

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.