wiki:WeeklyMinutes20120712

BIND 10 Team Call 2012-07-12

Actions

  • Shane will let ISC staff know about new name for b10-showtech (b10-sysinfo).
  • Jeremy will try to find out how we can get our system information code into a standard Python library.
  • Shane will ask Francis how hard it would be to build with the parts of the C++ libraries that work, using MSFT compiler.
  • Shane to create ticket about common resources like environment variables
  • Shane to create ticket about library naming - and other organizational - guidelines

Attendees

  • Shane
  • vorner
  • haikuo
  • Mukund
  • Jelte
  • Jeremy
  • Larissa
  • Aharen
  • Jinmei
  • Kambe

Sprint status

http://bind10.isc.org/query?group=status&milestone=Sprint-20120717

"showtech" name

http://www.cisco.com/en/US/docs/ios/12_3t/fun/command/reference/cfrgt_10.html#wp1098334

Cisco "show tech-support" command.

  • b10-showtech
  • show-sysinfo
  • show-tech-support
  • b10-sysinfo -> favorite by hum
  • b10-tech-support

Ticket to rename our tool. Shane will let ISC staff know.

Provide sysinfo python package

portable sysinfo provide to python community (not bind10 specific). Lots of projects do the same thing but re-invent it each time.

Jelte: seems like a good idea, but might be asked to make it more modular
Jeremy: plus someone else might be maintainer

No central repo (like CPAN). Get it included in official python distribution.
Jeremy will try to find out how we would do that.
See http://www.python.org/dev/peps/

Windows support

Francis did a lot more work on this recently.
shane: we want to do this properly for Windows and not just port of Unix ideas.
No specific plan, no timeline for this yet.

Will ask Francis how hard it would be to build with the parts of the C++ libraries that work,using MSFT compiler.

Resolver report

Set up test, just to see ideally how much performance we can expect.
-> sent to list
Analyzed (quite old) query samples to understand details of recursive work.
-> set to list
Now doing intensive analysis based on this (for example how often a particular cached name is used, ...)

Valgrind automation

Lets do it now.
Set up on CentOS, not automated because we need the exclusions list.
Not in repo.

Mukund: exclusions list has to be generated on the box itself.
Suppressions need to be on the build bot itself, put that into suppressions list.

[ fujiwara joins ]

Shane: Idea is to leave all existing bugs in place, but to prevent adding new bugs. We'll go back and fix those existing bugs later.

jreed will provide a valgrind suppressions list for review and then put in place (hopefully today).

Consistent way to define paths to socket files for all uses

Currently we may have environment variables but not used by all components using the sockets. What is a better way?

Central places to keep variables.
Jinmei: Several issues: inconsistency, different ways to define variables, ...
Mukund: there is a bug open about having library function to find common resources, like environment variables.
Shane: Would that help with defining, or just usage?
Jelte: Centralizing environment variable usage/interpretation

See
http://bind10.isc.org/ticket/1979
http://bind10.isc.org/ticket/841
http://bind10.isc.org/ticket/1903

*Need ticket for this specific issue.*

Middle term schedule and priority

Quite unlikely to complete a beta release given amount of work and time.

Basically need to reduce release features - if at all possible.
Or delay the release.
This would delay the resolver work.

Jeremy: from a marketing point of view we really need to do the release.
Larissa: I agree, we can make a marketing campaign around that; the resolver work is really important and it is unfortunate but it is this way

Next Release date

Maybe Thursday, August 16 (Note: release engineer jreed will be unavailable from Aug. 6 - 14.)
One week delay after the hardening sprint.
Key features: b10-sysinfo

Following release: With three 2-week sprints and one 1-week hardening sprint, the beta could be first or second week of October (as discussed in April at F2F).

Rename libraries

http://bind10.isc.org/ticket/2071 (libutil)

Jinmei: Several libraries have too generic/short names (cache, cc); want to reorganize to give a clear view of libraries
Jeremy: for example our data source libraries cannot be used by anything else (plugins) maybe in wrong location.

Some existing names under PREFIX/lib/:

libexceptions.so, libdns++.so, libcc.so, libcfgclient.so, libutil.so,
libdatasrc.so, libxfr.so, libbench.so, libnsas.so, liblog.so, libasiolink.so,
libutil_io.so, libcache.so, libresolve.so, libserver_common.so,
libcryptolink.so, libpydnspp.so, libfake_session.so, libacl.so,
libasiodns.so, libdnsacl.so, libtestutils.so, sqlite3_ds.so, memory_ds.so,
libdhcp.so, libdhcp++.so, libstatistics.so, libperfdhcp++.so

Jinmei: want to solve this at a bit of a higher level, if we want to avoid that we can solve this particular one

Need a page on the Wiki with a proposal for guidelines for library names/locations/, name change suggestions, and so on

Probably something we do before our beta release.

Need ticket for the generic guidelines.

A.O.B.

JPRS sent proposal for statistics work to bind10-dev.

Meeting over at 15:37 UTC.

Last modified 5 years ago Last modified on Jul 13, 2012, 7:18:16 PM