wiki:WeeklyMinutes20120627

BIND 10 Team Call

2012-06-26

Attendees

  • Mukund
  • Shane
  • Jeremy
  • Fujiwara
  • Kambe
  • Jinmei
  • Aharen
  • Michal
  • Stephen

Release Review (10 minutes)

Review of the recent release

Jeremy reports:

  • Branched on Wednesday, 2012-06-20 released on 2012-06-21 as scheduled
  • Discovered that "-u" did not work correctly, ticket created and fixed (check if lettuce test created) (LATER: #2078 created)
  • Noticed naming conflict with libutil (glibc, FreeBSD, NetBSD); re-ordered linking, ticket created to rename
  • Increased libdhcp version due to library changes
  • Jinmei provided changelog when needed, and responded on rest (about 25, not needed)
  • Released DDNS without any real use... any users? (Jinmei reports experimental usage)
  • n10 upgraded and running latest version for 1 week now
  • 20th release! (all on schedule)

Jinmei notes that xfrout infinite loop should be fixed. Shane needs to upgrade.

Sprint Status (10 minutes)

Overview of the current sprint status
http://bind10.isc.org/query?group=status&milestone=Sprint-20120703

Recursive Resolution Work (15 minutes)

Shane and Jinmei explain the research being done

Scalability Discussion (20 minutes)

Discussion about any open issues related to scalability work

  • Memory layout/efficiency
  • Asynchronous zone loading/transfers/updates

https://lists.isc.org/pipermail/bind10-dev/2012-June/003599.html
Threads vs. events? Begin with shared memory version? Question is: which to do first
We need to get the memory layout done first, so we have time to decide issues about zone loading when we get there.

Michal: what about the code names?
Jinmei: it's from Japan, like "good"/"medium"/"bad" (plum/bamboo/pine)

We have to choose between the option that takes more work but provides a better footprint, at least at the next sprint
Incrementally may be an option

Best way to move forward with #1976

It is in review, but it would cause regressions when merged.

Merge soon, even though it will cause some breakage, and introduce tickets for those items. (This is to avoid the code getting too stale.)

Python 3.2 as dependency

We currently have Python 3.1 as a dependency. Bumping it to Python 3.2 gives us some new features such as use of with on socket objects and verbosity options in unit tests (among others).

Should check package system on major releases (also include BSD and Mac OS X)

http://en.wikipedia.org/wiki/History_of_Python#Version_release_dates

Willing to commit to looking at which versions systems have. We can ask existing users how they feel about Python 3.2.
Jeremy thinks we need to find out which versions are in stable releases (for operating systems / package systems). Also October is our official release.

Will create a ticket to do the research.

Note: Some discussion that perhaps it might be nice for bind10-showtech to work on Python 2.7 as well as Python 3.x.
Our Solaris 11 and macmini lab systems have python2.6 in their base systems; so maybe consider 2.6.

Fedora 17 buildbot

Fedora is different enough that it has shown errors/problems with BIND 10 in the past.
Because this is a platform with many users and gets to be the base for a next-generation RHEL, we should have a Fedora buildbot.

Will add Fedora buildbot to virtual machine testlab

Googletest version

Requiring new version only means a lot of upgrades.

Old version is shared library, which you link to.
New version is just source; we can make a local static library which gets linked to in our tree.

Jeremy's workaround before was compiling into a shared object and making it work like it used to.

Google's motivation for the change is in the FAQ
http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog

A.O.B.

Sprint planning should be initiated at the end of this week. Shane will do this, with more respect/fear than last time!

Over at 15:31 UTC

Last modified 5 years ago Last modified on Jun 27, 2012, 8:53:30 PM