BIND 10 Team Call



  • Mukund
  • Michal
  • jinmei
  • Aharen
  • Jelte
  • Jeremy
  • Larissa
  • Fujiwara
  • Kambe


Beta program coming up (discuss)

Document what is not supported. Document what features are not production/official release.

Larissa: I have a document of beta program that I'll send around for review this week. We are going to call the release at the end of September a beta. We're going to have a few rounds of beta and respond to feedback. We're going to engage with existing customers, and also with other users. Jeremy and I are working on figuring out exactly what scenarios to point at users.
Jeremy: We're going to blog about different features, and tutorials too. We're also going to make walkthroughs, also for our own QA.

Jelte: please respond to larissa's question on -team (yes i have not done this myself yet)

Larissa: Anyone has any thoughts to express? About things that are not ready, the methodology we're using, etc.
Jinmei: What does methodology mean here?
Larissa: How we're going to ask them for feedback, and what kind of feedback we're expecting.

Larissa will send a document and we can provide feedback on that.

how we respond to type RRSIG queries

the current in-memory implementation handles this case as 'no such type of RR'. it will be more so in the revised version. it's probably inconsistent with the DB-based data src. what does the protocol spec say? what do other implementations do? and what should we do?

Jinmei: Discussed in #2165. How should the auth server respond to queries for RRSIG (which is unusual)?
Jinmei: Is it ok to keep returning NX for these queries?
vorner: I think it's OK. Unbound returns them in specific cases.
Jelte: If you are not returning RRSIGs, you cannot deny their existence as they do exist.
Jelte: Would it be very hard to include them in normal responses?
vorner: It would have to be handled as a special case; at least in the in-memory version the RRSIGs are attached to other RRs.
Jelte: Most existing implementations do return them
Jinmei: Depending on how efficiently we want to do that, it may/may not be difficult. One way is to make it behave like type ANY query and extract RRSIGs and send them out. But it will be less efficient. If we want to make it efficient, it may be trickier?
Jinmei: Is it specificially documented in the protocol?
Jelte: As far as I know, no.
Jinmei: We should check what was discussed before, but if other implementations return RRSIGs, we should also simply do the same.
Jelte: We should implement something simple even if it isn't that efficient, so it doesn't take too much time.

Questions about RRSIG queries:

Jinmei: We'll need a ticket for this one.
Jelte: I'll create one.

statistics plans

we probably need to have specific discussions on #2154 so that we won't get stuck. also it's probably good to check where we are based on the revised priority list.

Jelte: There were many comments on #2154. Unclear how to move on. I assume JPRS has read those.
Jinmei: Needs some generic discussion, and then continue the ticket.
vorner: The ticket was OK'd to be closed because it was a minor thing.
Jelte: Even though the comments are fundamental, much of the existing created code can be reviewed and merged to master. E.g., partial updates ticket.
Jinmei: It doesn't depend on #2154, right? In that case we can simply review+merge it.
Jinmei: Does it make sense to have a bit of design discussion first, and whether it is part of the dev plan for the beta release?
Jelte: Can you summarize the current points and send it to the list?
Jinmei: Yes.
Jinmei: How crucial is it to include stats counters in the plan? Can we defer it, if we can't make it by the end of September?
Jinmei: Even without it, the server will be reasonable and functional. If we require design discussion, let's have it first and then implement it, even if it means we cannot make it into the September release.

Jinmei: It's good to have additional counters, but how important is it to do that by the end of September?
Jelte: The current implementation in the tickets may be better than what's in master now (but we haven't measured it).

benchmark it too

Jinmei: If we can wait till the end of October, it's better to have that discussion first.
Jelte: For the sake of moving on, let's have both disucssions on the mailing list separately.

dead code

  • ifdeffed out
  • unused files
vorner: I noticed that compilation of some test files were disabled recently. In this case it's the old API tests for datasources, which are not updated and compiled, and they're not possible to compile.
Jinmei: They compile, but tests would no longer pass.
vorner: If we aren't going to compile or fix them any time, we should just remove them.
vorner: Other thing is there are large blocks of code commented out (in #if(0) style blocks)
vorner: I worry about them and want to eliminate dead code by removing them.
Jinmei: In general, I agree.
Jinmei: Commented out unit tests are a special case. I don't personally don't mind just removing them. We intend to do that for datasrc API, so we can exclude that from this discussion.
Jinmei: There may be special cases, but I agree otherwise.

Jelte: If you encounter dead code, first find out who's to blame! And if we don't know, just remove the code or make a ticket.
Jinmei: We should add a coding guideline to check in the review queue... just for our satisfaction

GIT issues

sometimes the automated git clones on the test systems fail like: The server side logs: Aug 28 10:13:46 git git-daemon[67549]: error: git-upload-pack died of signal 13

Jeremy: It started sometime ago. Doesn't happen on all boxes. Haven't found a definitive answer to it. Maybe has something to do with garbage collection, or it's hitting the user's resource limit on the client site.
Jelte: Are we sure it's not a network connectivity problem?
Michal: if it happens in the middle it cannot be garbage collection on the server, since it does that before it sends
Jinmei: When did it start happening?
Jeremy: About a week ago. It's still happening. Maybe 3 out of 4 times. Not all the time. Maybe it's because multiple jobs are hitting the same user at the same time.
Jeremy: I'll try to raise rlimits and also ask on the git mailing lists for troubleshooting ideas.

Test Code coverage

The automated charts are no longer automated. The python coverage is now working again (and just needs to be re-automated) but the gcov coverage is not working.

Jeremy: When we moved from Linux to FreeBSD server, I stopped automated coverage testing. When I started it up again, many unit tests would fail (when built with gcov compiler option). Because there are no debugging symbols, I can't see where it's failing. I  don't know if it's a GCC issue. I'll try with clang, and if it's not possible, I'll switch back to Linux.
Jelte: I had a problem with one specific version of GCC.
Jeremy: The Python coverage is working.

Jinmei: clang likely doesn't support gcov. We should find a gcc version and OS that's usable.

[on a related topic ...]

mukund: unrelated tests cover code; confirm the specific tests actually are testing their own code
Jinmei: I'm not sure if it's realistic to find such missing cases using this particular tool
Jinmei: We should use reviews and other such things to check that unit tests are written for code in their corresponding test code.

jreed: Try per library, different html reports for each and reset all gcov counters in-between.

Status of sprint

Jelte: 6 tickets left new. We are reasonably on track. Is anyone stuck on other stuff?
Jinmei: We should check the status of #2160. We can still wait.. other tickets don't depend on it.
Jelte: I'll put it back to the unassigned list.
Jinmei: #2154, #2157, #2155 - better remove these from the review queue for a while
Jinmei: Some of tickets with new status have dependencies on ongoing work, and it may not be possible to start them soon.
Jelte: If the dependencies are in review, we can pick up the dependent tickets. But if they are actively being worked on, we may pick up the background loading tasks.

Jinmei: I'll be offline starting Thursday. But I'll be working and can do something, but won't be as productive as normal.
Jelte: If anyone can't work on existing new tickets, please let me know so we can add others.

cppcheck suppression: in file or separate?

I'd like to propose preferring separate suppression rules in the separate list for main code, and use in-file rules only for tests (currently there's no suppression rule for the main code, so it happens to be the case)

We decide to leave this issue open for now as there's no consensus, and there are no cppcheck issues in the main code. We'll revisit it when necessary.

Over at 15:59 UTC

Last modified 6 years ago Last modified on Aug 30, 2012, 10:18:49 AM