BIND 10 Team Call 2012-08-14


  • Shane
  • kevin
  • Mukund
  • Jinmei
  • Kambe
  • Jelte

Sprint status

Is there a review bottleneck?

Jinmei: relatively longer, but no so bad if we try to pick up at a higher priority

Do we need to think about testing the full functionality and/or benchmarking it (both for speed and memory)?

Jinmei: yes we should definitely do that
Jelte: good point to run graph generating thing again
Jinmei: once we merge into the main program (b10-auth) we should do that; probably happen in the next sprint

(Prototype) Release status

Release scheduled Thursday...
Not sure whether Jeremy will branch from last week some time or latest or...? Will need to check when he gets back tomorrow.

September release

This release will be classified as a BETA. (Personally I think we should call it an ALPHA, but apparently People Have Been Told so this must be called a BETA.)

Based on expectations we decided that we were going to include:

  • our more memory-efficient in-memory data source
  • non-blocking loading of in-memory data source

Jinmei suggests that because we have no ISC all hands meeting, we will have more developer time (this is true), so may be able to add an additional functionality. His possible suggestions include:

  • supporting incremental in-memory zone update (after ixfr-in/ddns)
  • supporting shared memory version of in-memory data source (maybe too big, but just in case)
  • xfr cleanups
  • generic zone parser/loader

Jelte suggests that early-adopters may be put-off if zones cannot be loaded.
Shane also notes that we can omit a lot of checks and still have a good, basic working zone loader.
Jinmei still a lot of work. Excluding a lot of checks won't magically make it a lightweight task.

Shane will check with Larissa and propose we go with zone parsing/loading.

Jinmei notes that target customers may need shared memory data source.

December release

We should also begin considering what we will put in a follow-up December release. We were months behind getting our Comcast contract, so I think we can safely defer the recursive resolver work and concentrate on the authoritative server.

The above list seems like a good list, but is missing user-interface work. I'd like to defer that discussion to a later team call, or perhaps a...

Jinmei notes that the release should have unique features for BIND 10 - a real reason for people to use it. What it is can be discussed later.

Face to Face Meeting

Was considering having a mini-BIND 10 summit at the ISC All Hands meeting in the middle of September, but that has been cancelled. We can have a "real" face to face meeting, although obviously we need time to plan it. Some proposed dates:

2012-w43 (2012-10-22 to 2012-10-26)

One issue here is that maybe it is too soon.

2012-w46 (2012-11-12 to 2012-11-16)

This is the week after the IETF in Atlanta. I don't know if this is likely to be a problem for anyone on this call, but it may be a bit tricky for people attending the IETF.

2012-w48 (2012-11-26 to 2012-11-30)

This is the week after the Thanksgiving holiday in the US. It should be okay, but getting preparation in advance may be tricky as a lot of people at the home office will be out.

What we would actually do at the face to face meeting would depend on the dates. If we met at the end of October, then we would have 2 months before the end of the year, and could plan quite a bit of the release there. If we waited until later, we could spend cycles talking about post-2nd release issues (not sure what they are exactly, but we should by then).

Jinmei: if we want to plan December release, the only choice is October or not have any face to face meeting
Jinmei: not sure if really good in terms of cost & overhead versus benefit, in this case; in general it is nice to it may make sense, but we already have pretty concrete ideas about what we are going to do, and how we do that
Jelte: could do an actual ticket-level planning for next 2 months until release, but not worth it for a full trip for just that!

Shane: leaning towards not having a face to face until 2013 then...

In-memory Data Source as "Built In"?

Jinmei asks, is it okay to always include it in the main library or should it still be dynamically loadable?

Jelte: don't know how much I like this setup (don't like to call it a "cache"!), no strong opinion on whether to keep it by default; using zone files is also hard-coded exceptions (the MasterFiles? 'datasource')
Shane: don't want to carry code that we don't use
Jinmei: code-size it's not a big deal, functionality-wise you can disable by configuration; but do we want to make it replaceable
Jinmei: also database backends will depend on other libraries
Shane: should still be able to load a different specialized in-memory model
Mukund: should we support loadable data sources? could conditionally compile them...
Shane: was originally designed to support proprietary modules though; not sure if still necessary, but that was the idea

Shane: from a "purist" point of view, prefer not making it special
Jelte: public API does not support everything you might need, for example the "load zone" call
Jelte: want some form of optional cache, so make it a data source - but need to be sure not to mis-use this feature (like we do, now, actually :p)

Jinmei: not a big issue so we don't need to change it for the September release

Statistics Plans

Jinmei suggests we discuss the following:
We should have a reasonable set of goals that will be included in the September release, based on:

  • the plan and current status of the JPRS team
  • what we really need to have by the end of September
  • what will happen after the September release
(17:26:37) naoki.kambe: 2135 is ready for reviewing
(17:26:56) naoki.kambe: 2136 and 2137 are in reviewing
(17:27:51) naoki.kambe: 2138, 2179, 2154, 2155, and 2157 are ready for reviewing.

More tickets to come:

There is additional work not yet in tickets:

Current tickets complete estimated at about 60% of overall work. We will need to take this into consideration during sprint planning.

(17:45:07) jinmei: so, can you submit a revised list of plans with priority, specifying 'must be done by sep', 'hopefully be done', 'optional', etc?
(17:46:33) naoki.kambe: ok we can categorize into 3 priority groups
(17:48:51) naoki.kambe: after the end of sept, we will implement into xfrin and resolver
(17:49:18) naoki.kambe: yes we three will continue to work
(17:50:20) naoki.kambe: and after the end of sept we will revise the statistics algorithm in auth


Will be sending request for estimates early as Jelte is away Thursday/Friday?, Shane Saturday onwards. Jelte will try to send the Monday, but will be later in the day for him. Some additional tickets will need to be included from later this week.
Maybe have sprint planning call on Wednesday instead? Will confirm via e-mail.

Last modified 5 years ago Last modified on Aug 15, 2012, 1:13:58 PM