BIND 10 Team Call 2012-10-29


  • Jeremy
  • Shane
  • Mukund
  • Jeff
  • Jelte
  • Larissa
  • Michal
  • Kambe
  • Aharen

Sprint Check-in (10 minutes)

Usual progress check of sprint

Jelte: Discuss new estimation method?
Michal: I think we should wait another sprint.
Jelte: Proposals in (or preferrably before) Thursday.

related: we may have to revisit planned tickets for the rest of the sprint. Major open ones depend on #2369, but it doesn't seem to be available (much less completed) soon. maybe #2376 and #2377 (using a faked lexer class) and #2384. We should also discuss prioritizing #2369 and #2198 so we can focus on more important one.

Mukund: Problem with current #2369 is that it reads everything into memory - problem for big zones.
Jinmei: Should only need 1 token buffer.
Mukund: Input object is destroyed when done parsing a token?
Jinmei: if we are not using $INCLUDE, we create the parser object when we open file and destroy it when done parsing
Mukund: Please take a look at #2369. Maybe I don't understand the ticket properly...

Jinmei: We can use a snapshot version, if the behavior is there.
Mukund: Yes, we can do that.

We'll put this to review, merge, and we can make a refactor later if necessary. Should not change interface.

Jinmei: Another option is to pick up unrelated tickets. There are a couple such ones.

Background zone loading waiting on a review to complete for one ticket.
Jelte: anything useful to document for administrators?
Jinmei: not necessarily needed?

#2369 vs #2198
#2369 is a dependency for other work, so that is priority

Alpha 2 Release Discussion (10 minutes)

Report of discussion between Larissa, Jeremy, and Shane over alpha 2 release

  • background zone loading not yet done
  • Jeremy pointed out feedback from first alpha not yet reviewed

ISC only (sorry), please do not modify:

We are going to create tickets.

Shared Memory for Beta? (10 minutes)

Jinmei showed impressive results in memory size reduction over BIND 9, but we need shared memory to get full advantage. Discuss!

Jinmei: will be a choice between this and another feature (probably zone parser)
Jelte: would love this, but would prefer real functionality now (we can call this a "win" whenever we add it)
Jelte: we also need documentation on worst-case scenarios, if we declare this a "win" (for example does your memory double with XFR of a new zone)

Quick Proposal: adding a blank line between methods declarations with doxygen for readability (? minutes)
i.e. add a blank line before the second \brief:

    /// \brief Return the token type.
    Type getType() const;
    /// \brief Return the value of a string-variant token.
    const StringRegion& getStringRegion();

Everyone likes vertical white space.

Jinmei will document.

Michal will update the coding guideline to describe #include style.

Usage policy about 'using' directive/declaration, especially 'using namespace' (? minutes)

Different people seem to have different preferences, and we are not really consistent.
It has both pros and cons, but it would be better if we have some general consensus.
google's policy seems to be sensible to me: in short,
no 'using namespace'
declaration is okay: 'using boost::shared_ptr'
alias is okay 'using namespace shortname = some::very::long::name::space::that::would::make::lines::too::long'

Jelte: I agree, tend to not like using "namespace", even if it makes code shorter (just fixed a bug about this today!)
Michal: I stopped at using std; or using boost;
Michal: But it can be useful when we are writing a test.

Discuss on list.
Jelte will bring up on list.

Spec for parameterized statistics items (? minutes)

See #2157
do we want to have something like this in the spec file?

              "item_name": "qtype",
              "item_default": {
                "a": 0,
                "ns": 0,
...about 70 of these
                "dlv": 0,
                "other": 0
              "map_item_spec": [
                  "item_name": "a",
                  "item_type": "integer",
                  "item_optional": false,
                  "item_default": 0,
                  "item_title": "a",
                  "item_description": "Number of QTYPE = A queries received"
...repeat this for all types.  And do the same thing for, e.g. resolver statistics?

Jinmei: Raising issue, don't have alternate proposal.
Michal: Think we should open a ticket to find a solution.
Jinmei: Worried we will be relutcant to change.
Michal: We can push this to next sprint, so we won't forget.
Jinmei: If we deal with it soon, then okay. My concern is just creating a ticket and forgetting about it.
Jelte: It may not need fundamental changes...

Jinmei: if Aharen-san is okay with this I can live with the current format for a short-term workaround

  1. remove rrtype stat from 2157 and merge
  2. merge current 2157 and start followup discussion and tasks immediately
  3. merge current 2157 and try to have follow up discussion (which may or may not happen)

Option #1

Ticket size

While it is good to have nice small tickets, we should not go too far. We then lose the context and they don't fit well together and i

At estimation time, we can comment on the size of tickets, and try to adjust if necessary (either smaller or bigger, as appropriate)

Build failures

We should fix centos+valgrind, macos+clang-analyzer, netbsd failures so we have a green page:

CentOS + valgrind *is* a regression - need to identify the commit; Jeremy can find after all; libdhcp tests

-> Shane will ping Stephen for this (that was wrong commit)

Jinmei: DHCP uses unsafe techniques which tend to cause memory leaks (for example using "new" directly)
Jelte: probably need more direct communication; need to look at buildbot directly (seems like they merged a branch which failed)

MacOS+clang-analyzer, always had issues
jreed: has three very minor fixes in my tree; I will get review via jabber since so simple.
Shane: discussed annotations to code?
Michal: errors in Boost includes
Mukund will run and try to see what is going on.
Shane: might need to run manually periodically instead of being part of build system
Michal: still wouldn't finish
Shane: then we have to disable if we can't get it to build
Michal: could keep our own Boost headers for buildbot

Python code core dumps
Jinmei: need a stack trace, main developers should be able to log onto that machine
Michal: maybe we need a ticket for this issue?
Shane/Jinmei?: okay

Over at 16:03 UTC

Last modified 6 years ago Last modified on Nov 2, 2012, 9:05:54 AM