BIND 10 Team Call



Shane: Link from to Gantt chart
Shane: send mail concluding interface discussion
Jeremy: send mail kicking off library versioning discussion(s)
Jinmei: send mail about exceptions in destructors


  • Shane
  • Jelte
  • Fujiwara
  • Stephen
  • Jinmei
  • Aharen
  • Kevin
  • Larissa
  • Michal
  • Jeremy
  • Mukund
  • Kambe

User Story Gathering (5 minutes)

A quick update on the status.

Sprint Status (10 minutes)
Was a kind of blocking ticket, which seems to be mostly ready and we can now accellerate the development. Gut feeling cannot complete in one sprint.

Usability Development Status (10 minutes)
Seem to be about 1.5 weeks behind now, need to discuss with Larissa & Joao, then talk to steering committee.

Jinmei: Link from BIND 10 page to this chart?
Shane: No, good point, will put that up there.

Meta-Source / Container of Sources Conclusion (10 minutes)

I suggest we conclude this discussion in the biweekly call tomorrow. Assuming participants will understand the basic design tradeoffs, we'll basically just have a quick voting to see if there's a majority, and, if not, will just pick up either one by tossing a coin.

Detailed version of the technical discussion is at:

Shane: no preference
Jelte: (very) small preference for container
Jinmei: container
Michal: (very) small preference for container

Stephen: collection seems like more work, if we're behind it doesn't seem like a good idea
Jelte: kind of think it seems like the same amount of work
Jinmei: Meta-data source does have less code, I am sure, but it is not trivial, I don't know if it is marginal or substantial. I don't think anyone can be sure at this point. The important point is that Stephen prefers the meta data source approach for that reason.

Shane: we'll go for the container model, since it seems slightly cleaner architecturally

Jinmei: where is this? configuration?
Shane: I guess it is...

Interface Detection (5 minutes)

I just want to make sure we're in agreement, based on mailing list discussions.

Due to technical reasons we have to bind to different addresses.

Shane will send mail concluding this.

Jinmei: only for IPv4, it might be better on IPv6 to use the alternate method (IPV6_PKTINFO)

BIND 10 Used in Production (?)

Jeremy: all of the lab computers used by BIND 10 have /etc/resolve.conf pointing to our open resolver (except the Mac Mini). Our two public resolvers are running on our git server and on ...?

AS112 server:

        "opcode.query": 12356027683, 
        "opcode.update": 199657839, 
        "queries.tcp": 436240,

Averaging about 12k queries/second.

Jinmei: Does the AS 112 server work more busily than BIND 9?
Jeremy: We don't know. 8 auth processes around 35% CPU usage.
Jinmei: That seems quite high. What happens if we only run 1 instance of auth? 1 should be easily about to handle that rate of queries.
Jeremy: Maybe I can play with it.

Git Server Migration (10 minutes)

Library versioning (10 minutes)

Propose that only increase once per release if needed; but do on first need (first noticed).
Also requested to build software using our libraries outside of BIND 10, like with bind10-host for example.
Could set up something to extract something outside of the source tree; build against a system installed library. Check whether our libraries are usable by external programs in the first place.
Could check old binaries using new libraries, for example.
A static method could be to extract the symbols and compare those (if version the same), but it would only catch changes in API, not ABI.

Jinmei: we should first establish a policy about compatibility, and when we can allow binary incompatibilities and so on

Mukund: change ordering of libraries to avoid this problem, happens in other projects
Jeremy: might be FreeBSD's linker...
Jinmei: yes should separate our building problems from general API/ABI issues; even if versioning solves both problems

Shane: I think we need to take it to the list.
Jeremy will send kick-off message.

Exception from destructor

Apparently we don't seem to have a consensus on whether we should allow an exception to be thrown from a destructor.

With other variations, we'd have roughly two positions:

  • We should basically prevent destructors from throwing/propagating exceptions even if its cost is quite high, and only if by doing catch-all catch in the destructor.
  • We should allow a destructor to throw exceptions if it seems to be okay in terms of how the class is used.

I think we should have a unified consensus on this and document it in the coding guideline.

Intent was to introduce discussion. Perhaps continue on list?
Jinmei will send mail about this.

An API Framework of Supporting Various Types of RDATA

Sent before the face to face meeting, so perhaps buried in inboxes. Would like feedback on this!

Over at 15:33

Last modified 6 years ago Last modified on Jun 28, 2012, 2:25:16 PM