[bind10-dev] Minutes, was Proposed agenda for BIND 10 call on 2009-09-17

[Shane Kerr]

Hello,

Some minutes from last Thursday's call.

Attendees:

Jelte
Michael
Shane
Jeremy
Evan
Fujiwara-san
Kambe-san
Larissa
Feng
Likun
Jin
Jinmei

On Thu, 2009-09-17 at 10:27 +0200, Shane Kerr wrote:
> 
> Agenda for the BIND 10 team call:
> 
>       * Agenda bashing
>       * AP from previous meetings
>               * Shane to summarize code standards discussion and put on
>                 Trac site

Not done.

>               * Jin to send recommendation about patterns to list

Shane & Feng discussed this before the call. It turns out to be a
misunderstanding. The idea was simply to use the same names for design
patterns and take advantage of best practices in this area.

Evan: There is a design pattern Wiki that collects all of this...

AP: Evan to find the design pattern Wiki and send a mail to
bind10-dev at lists.isc.org

[ NOTE: Evan has done this:
  https://lists.isc.org/pipermail/bind10-dev/2009-September/000137.html ]

>       * Face to face meeting reminder: 2009-10-26 to 2009-10-30

Feng: When are Larissa and Shane going to talk with network operators
about BigTool?
Shane: This will happen at RIPE meeting and NANOG, before the
face-to-face meeting.

Shane: If you have topics for the agenda, please send to Shane or to the
list. There will be coding time, and less high-level discussion, but the
week will still be quite dense.

>       * BIND 10 Reality Check (Shane)
>               * Current status
>               * Big picture
>               * Current goals 
>               * Deadlines
>               * Working style
>               * Anything else...?

Shane mentions that there seem to be concerns and trouble working
because of the lack of a big picture. People are uncertain about the
current goals, and lack understanding of the deadlines. The working
style may be causing inefficiency, because of long time between e-mails
and replies. These issues need to be addressed as soon as possible.

Michael: Yes.
Jelte: RTT from discussions take a long time... a lot longer than they
could be.
Michael: Discussions increase right before conference calls.

Shane notes that perhaps we could increase efficiency by having people
working on multiple tasks, so they blocked waiting on feedback.

Shane mentions that Feng pointed out we have a star topology now, with
everything going through Shane. This should move to a web mesh shape.
Larissa: A massive star, and a massive web are both bad. Dispersed team
is a problem.
Jabber chat room? Sprint goals.

Michael: We should put hours available on Wiki?
Shane: Sure, makes sense. Kind of office hours.

AP: Michael to put page on Wiki with "hours available".

Jelte: Not only dispersion of people, but big picture is there, and a
lot of ideas, but in people's heads, but not much to work on. Slightly
less big picture is *very* missing. Michael has great ideas, but I don't
have any way to see those.
Shane: Work with Jeremy to document ideas in a template?
Michael: Too many ideas but not enough work!
Jelte: We should pick some things and do them.

Jinmei: Long RTT is that we are currently discussing high-level
abstract ideas. In many cases we see proposal, and we think it is
generally reasonable and don't have any details, so tend to be silent.
If one wants quicker feedback, we need to explicitly ask someone for
sanity check.
Jinmei: One positive example is Jeremy's benchmarking. We got a lot of
discussion based on that.

>       * Benchmarking rundown (Jeremy)

Jeremy built shell scripts for testing, installation.

Jeremy: What are specific zone sizes and tests?
Michael: 10k-100k very small zones (maybe 16 records)
         zone with 10k records
         zone with 100k or 1m records
Jinmei: Recommend using query pattern from F root.

Jelte: Maybe not nice to publish benchmarks of competitors products.
Michael: Agreed.

>       * Component status/discussion
>               * C-Channel (sounds a bit like "sea channel"... HAAR!!!)
>                 (Michael)

Michael: libisc does a lot of stuff... used by c-channel...
Could use libisc for first cut?

Shane: Do it.

Michael will start working on client side of it today.

Jinmei: Why do we need libisc?
Michael: We don't but the current stuff relies on it.

>               * Configuration (Jelte)

Jelte: been torn between two general ideas: 1) experimental name/value 
repository, 2) specification language which generates stubs &
skeletons
Shane: What are the main benefit/drawback of specification language? 
Jelte: It catches errors, going to use generated code, but is an extra
step.

Michael: not use generated code right now, because it is too early to
decide?
Michael: why not use XML?

Shane: how do you feel about using your original prototype?
Jelte: but with an XML base? we have to add modules without updating
the configuration manager
Jelte: will go with this direction

>               * UI (Feng, Likun, Jin)

Likun: UI still needs some comments, need ideas from Michael about
package format between BigTool and PackageManager
Michael: assume any format is possible, message-oriented
Likun: Can you provide document about how config manager will
communicate with other modules?
Michael: Doing that today and tomorrow!

Likun: Most important thing is comment on UI
Shane: I'll look at it, makes sense for Jelte to look too.

>               * Statistics (Kambe-san, Fujiwara-san)

Kambe: sent mail about this - plan to write prototype program, subject
to XML data type, suggest statistics list. It was described in mail
sent.
Jinmei: In the meeting with Kambe-san and Fujiwara-san had concern
about relationship with configuration channel and statistics module. I
don't know how this can be solved. Will Michael's document help or
not? Whether JPRS people should talk to Michael?
Michael: vision on command channel is same as before, but no API
wrapper yet.
Jinmei: wondering whether JPRS can continue without knowing the
c-channel details.
Michael: if sending messages and doing something with them, can be
done by send/recv for now, and replaced with functions later
Jinmei: you mean the standard system call?
Michael: yes

Kambe: okay with that


Jeremy: maybe I don't understand component, but maybe not needed. If
configuration component stores statistics?
Michael: Collector for modules
Jeremy: where would you configure what you want
Michael: tell config daemon what stats you want, and what granularity

>       * AOB

Jelte: on vacation for next 2 weeks
Jinmei: if you want feedback before vacation please explicitly say!

Jeremy: added accounts for Kambe and Fujiwara

Feng: according to your proposal, will get some documents, put into
wiki
Shane: that's it

Jinmei: update on dns message API! thought about main message API,
will be pretty straightforward except for rendering API, which can be
different depending on data source (high-performance, wire-format
database, or most generic but low-performance database). Thinking of
abstracting that, so we can use a common API while still having the
opportunity of improving the performance. Will send initial proposal
by end of this week.


--
Shane