Notes from the BIND 10 call.



WebEx Support

Shane: Did not set up WebEx. Joao suggested Google Wave, which seems like it might work Good Enough. Shane will send invites to people and we can play around with it beforehand.

AP Shane to send some Google Wave invitations (he only has 6 left, so this will not be to everyone)

Daily Check-ins

Shane: Has this been helpful?

Michael & Jeremy: yes

Shane: what about weekly updates? Larissa: maybe there is a 2 or 3 week adoption period?

Michael: is this too much?

Shane & Larissa: no!

Action Points

  • Shane to try to make a graph of timeline

Shane: made a chart by hand (in pencil!), Jeremy has seen, should I publish that?

Jeremy: no

Shane: okay, then still in progress

  • Jeremy to set up automated coverage testing

Jeremy: Python and C++ tests. Problem with C coverage tests, since include directory was created, and now has wrong results. Jelte & Jeremy discussed changes to source tree layout to fix that problem.

Shane: going to be re-arranging source tree?

Jeremy: Don't know if Jelte will do it, or if we will ignore it for now. Some tests are using headers from include tree, some using from their own directory. Proposal to get rid of "include" directory, or to have everything put into a cpp directory and every project underneath it. It's an easy fix, but it will be touching a lot of files. Other idea: lib/dns/cpp/dns, where "dns" is repeated, then references to headers would be fine.

Michael: why can't -I take care of this problem?

Jeremy: Even if you use -I, in some cases it will use the current directory by default.

Shane: annoying because your headers are not in the directory you are working in.

Michael: Yes... probably using cpp/$module makes more sense then (at least for libraries, but not for bin).

Shane: when do we need to decide on this?

Michael: yesterday!

Jeremy: Important because of merging branches.

Jinmei: BIND 9's way is another approach. Maybe not very good... adding include/dns subdirectories in main cpp directory.

Shane: I find that very hard to work with.

Michael: I like having header files right there in the directory. But with BIND 9 you don't have to ship header files you don't want to ship.

Evan: Why BIND 9 way is annoying, I find I have to go up and down directories more in BIND 10 than in BIND 9. This gives a lot of typos. BIND 9 is better than what we have now!

Jeremy: We also need to think about later goals if we are going to ship individual components separately.

Michael: I thought we might have a module with cpp, Ruby, Python, whatever. Maybe those bindings can live in the same directory?

E-mail sent 6 days ago.... need to reply to this.

AP Evan to reply to unit tests & include symlink tree mail

AP Michael to reply to unit tests & include symlink tree mail

AP Shane to reply to unit tests & include symlink tree mail

Jeremy: Python coverage tests are automated on commit.

Shane: can we put that on the Trac wiki?

Jeremy: yes, and also put into the blog article

  • Jeremy will be writing a blog article about the coverage test

Shane: after C++ shift we can publish the blog article?

Jeremy: it's misleading now.

Shane: okay lets wait to publish until it's fixed

  • Jeremy to update review process to say to cut & paste checklist into review

Jeremy: Done

  • Jeremy to make sure files are automatically checked for copyright

Jeremy: A copyright check is automated on commit of trunk and lists the files missing a copyright. Needs to be cleaned up a bit to not exclude some files.

Michael: Does it check for the date as well?

Jeremy: No, not yet. Will do that.

Subversion Trunk Shuffle

Jeremy: shuffle was done - around 10 tickets for different tickets created. Jinmei closed some of them, but he is also creating new tickets.

AP Shane to assign reviews

  1. Remove parkinglot - done yesterday.
  2. src/lib/cc/ruby - remove it?

Jinmei: should we use "svn mv" or "svn rm", but trunk can't include this.

Shane: if we want to add it later as "unsupported" or whatever we can, but

  1. host command - move or rename it?

Shane: rename to b10-host or something like that?

Michael: if it's the same, just leave it as host?

Shane: we can rename it later

Shane: can it be reviewed? We could also include as "example" or something like that.

Action Task List

Shane: Good enough to send to bind10-dev list

AP Shane to look at releng checklist

Branches for RelEng

Jeremy: What branches to autobuild and run tests, etc? (Now I am using trunk

and since nobody is using parkinglot and using their own branches I am not getting any tests on commit anymore.)

Jeremy: doing tests on trunk, now a lot of people are using their own branches... what do people want me to build?

Michael: unless requested on private branch, then don't worry about it

Jeremy: Python tests are not part of the "make" framework. Testing those with a shell script.

Jeremy: If one of the googletest fails it won't do the rest of the tests and the coverage results are skewed.

Jinmei: I thought gtest had an option to customize this? We should take a look at the manual.

Michael: You're more likely to fix the test if it fails.

Other Discussion

Jeremy: Also doing builds & tests on Solaris and NetBSD in addition to the Linux. Generating HTML. Tests are failing on NetBSD and Solaris that are working on Linux.

Michael: are we adding Mac to those as well?

Jeremy: I'd like to add that. Is there one at ISC?

Michael: I think there is but it's not really part of the lab.

Michael: Do we have FreeBSD?

Jeremy: I wasn't sure which lab computer to use for this.

Michael: Can we use virtual machines from the lab?

Jeremy: Yes, but setting up from scratch would take a day...

Jeremy: You have 3 servers. Is one of those available for me?

Jinmei: Yes, but Eric also asked me if he can use some of the machines, so maybe we need to do some co-ordination. You can at least use one, but I need to check that with Eric.

Jeremy: Okay, will e-mail.

Michael: Talked about valgrind.

Jeremy: I was going to look at installing valgrind on a Linux box.

Michael: Was very useful.

Michael: Don't use valgrind other than as a valgrind report - some things work differently when run that way.

Jeremy: Doing automated cppcheck reports, found a bunch of bugs which are fixed.

Shane: These are all on the web site and go to the trac wiki?

Jinmei: I found that it reports a non-neglible number of false positives. Doing the check is okay, but might be distracting due to false positives.

Shane: Maybe as part of release checklist one of the coders goes through these?

Shane: And you were looking for Python checking but none work with Python 3?

Jeremy: yes I've tried 5, there are more...

Michael: A book on Python checking released recently.

Jeremy: We have the Boost header tree included with our source. Jelte found some problems with this. Yesterday when set up the Solaris builds it had a couple of failures with missing Boost headers, so I looked and I have many different versions of Boost. All of us were using a mismatch of Boost headers to do our build. Since we're using a mismatch already do we even need to provide these in the first place?

Jinmei: Problem is that we only have a subset of Boost in the "ext" directory. We should either have a complete set or only have the difference.

Michael: We did it this way because the Boost people recommended to pick a version and ship it. We can ignore that advice, or we can do what they recommend and only ship what you actually need. NetBSD has the "no standard include" option.

Evan: What are we using from our tree that we are using? I didn't install anything and it is working...

Jeremy: I added 2 more header files. Maybe this is a Solaris issue...

Shane: Lets do what we're doing now.

Jeremy: If we don't notice it, BIND 10 might behave erratically.

Shane: You're right.

Evan: Have our test build environment not include anything other than our standard source...

Shane: Solaris has no Boost, so that is a good test environment.

Evan: We can call it something other than Boost... extboost or something like that. What do the Boost people recommend about this?

Shane: Non-plan to look more closely for future releases

Jinmei: I wonder whether we need to implement TSIG in C++. I simply don't know. It was never clear. Need to have it for Y1 in some way. If we need to implement it in C++ or Python, it will take some time, it will not be super difficult, but since the schedule is busy, it might be crucial whether we need it in a specific way - or use a 3rd party library.

Michael: Would it be hard to in C++ message API?

Jinmei: Not difficult, but we need to complete everything in say 3 weeks, so I am afraid it might be too ambitious to do in C++ in 3 weeks time frame.

Michael: Why is TTL a class? Trying to find where things run is tricky. The TTL being a class seems to be a part of that.

Jinmei: One reason is that it will be strictly typed, so we cannot accidentally passed an integer in a different context.

Michael: But a TTL *is* an integer?

Jinmei: Consider a function that expects TTL and an integer type, then there is no chance for a mistake.

Michael: But we're trying to make it easier for people to use this stuff...

Jinmei: I don't argue that the current implementation is ideal! Also, by making it a class we can also define other useful methods like toText() or fromText(), such as "2D" or "1W" then we can easily integrate that into a class.

Michael: We'll have to see how it develops. I can be convinced.

Jinmei: I am also open to other suggestions. Making it a class might be overkill.

Michael: Sometimes I want to work with unsigned character strings, and not character strings.

Jinmei: We first need to check the constructor specification.

Michael: Only accepts signed version.

Jinmei: No better solution than casting.

Jinmei: Looking at Jeremy's schedule, what kind of maturity we expect for the year 1 product? We have alpha, beta, RC, final. That looks like "production quality 1.0" version. But realistically it will probably be beta status.

Shane: It will not be production quality.

Last modified 8 years ago Last modified on Feb 16, 2010, 1:50:12 PM