wiki:WeeklyMinutes20120214

BIND 10 Team Call, 2012-02-14

Attendees

Shane
Jeremy
Jinmei
Stephen
Jelte
Aharen
Fujiwara
Michal
Larissa
Kambe

Next 2 Releases (Last of Year 3)

A bit wonky because we had a 1-week sprint.
Scheduled for Thursdays March 1 and March 29.
Sprint ends February 21.

Release on February 23? Seems okay. Re-evaluate at sprint planning on February 21.

April Meeting Status

Men & Mice can host the BIND 10 meeting in April. Waiting on ISC executive approval.

NSEC3 ticket progress/concerns (if any)

  • do we want consistency checks on auth level (i.e. in query.cc) or only in the datasource (for instance whether returned NSEC3 records actually cover the data, have optout set correctly, etc). I'm guessing no, but just want to make this clear

Michal: We don't want to do too many checks. The database backends should be checking themselves so it should be safe.

Jinmei: I agree and I know in the current implementation the policy is not so consistent; we do things that are not necessary. I think we should have a clean-up ticket to reduce the amount of checks to a reasonable level. We should also probably catch exceptions from toWire() method, so we will not crash even if something bogus is returned from the data source, which can frequently make toWire() throw exceptions.

Jelte: Definitely!

Michal: But if the data source provides bad data we should return it to the user, as it may have been intentional. We need to check if a pointer is NULL, of course.

Jelte: Jinmei mentioned the same thing. We probably do too much checking right now.

Ticket #1612

TODO: add separate ticket to remove checks

Jinmei: NSEC3 ticket progress item was added by me, and it was a more general question. Any trouble working on tickets because of unclear descriptions?

Jelte: It did take me quite a long time to figure out how the unit tests work.

Jinmei: Because...?

Jelte: Also think more on the level of the whole system about how we need to send out these additions. So we don't say "we have NSEC3 support but you can't use it right now". These should go in the next-sprint-proposed queue if necessary. For example, do we need to update the zone loader?

Default XFR Strategy?

https://lists.isc.org/pipermail/bind10-dev/2012-February/003041.html

Shane: I saw no consensus. Any ideas on how to push this forward, or if we should?

Jinmei: My understanding is the same as yours. I suspect we will end up preserving BIND 9 behavior.

Stephen: Do we have to preserve the BIND 9 behavior in "raw" BIND 10, or only in people who are moving across from BIND 9?

Shane: I think that may be right. With BIND 10 default to "closed" and with BIND 9 conversions go ahead and preserve BIND 9 behavior.

Jeremy: "closed" means nothing can access it? Or localhost/localnets?

Shane: For XFR I think probably nothing.

Recommended Method of Reporting Issues?

Jeffry Spain mentions off-list: "In general how do you and the bind10 developer group prefer that feature inquiries like this be made? I can post questions to the bind10-users list, as I have been doing. I believe I can also create tickets in your system myself if that is preferable. Please let me know."

Jeremy: I think first posting it to the list is fine, so he can get feedback, and then he should create the ticket.

Michal: I think it depends on what is better for him. He might come to the jabber room directly.

Stephen: It won't scale up...

Michal: I think it will.

Stephen: I think posting something on the list, rather than creating a ticket. At least on the list you'll get some feedback. The danger of just creating a ticket is that it disappears into the backlog and nobody hears about it again.

Shane: I do review the queue.

Stephen: Can users change milestones?

Shane: I don't know, but it may get lost.

Shane: I guess we probably do want this to come through a mailing list.

Stephen: It also avoids creating redundant tickets.

Michal: And people can say "you can already do it this way".

Shane: So send people to the list.

Jelte: Mild preference for list, but either is okay.

virtual declarations in derived class (again)

We discussed before, and seemed to have some level of consensus https://lists.isc.org/pipermail/bind10-dev/2010-July/001191.html but it didn't apply to the coding guideline and I have had the same discussion in recent reviews. Maybe it makes sense to discuss this and if agreed update the guide accordingly.

(One popular C++ book also recommends the "redundant" virtual: "Prefer to add the redundant virtual when overriding a function. It makes the intent clearer the reader." http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586/)

Jinmei: appear to do this in most cases already. Whatever we decide should be added to the guidelines. Vorner: adding virtual destructor implies that this class is to be subclassed. God to add virtual anyway. Shane: sounds as if we should update guidelines to include this.

TODO: update style guidelines (Shane)

whether to regenerate man pages/HTML guides in branches

See this: http://bind10.isc.org/ticket/1596#comment:8

Jinmei: Do we want to explicitly exclude from repository, so we don't accidentially include it?

Jeremy: If they're not in trunk, we have to figure out how to include for release. I only regenerate if they are changed.

Stephen: Why don't you make all the documentation from scratch?

Jeremy: It didn't make sense to update the timestamp on a file if it was the same.

Jinmei: Propose to exclude from repository.

Jeremy: One benefit: When I add distcheck, documentation tools will report problems here. Right now we don't have any way to test this.

TODO: make 2 tickets for this, one for documentation and one for log messages XML (Jeremy) [This became #1686 and #1687.]

Auto-generating backtraces/crash info

Michal: I answered the ticket about resolver crashing, and discovered it was a segfault. Asking for a backtrace from a user is possible but not always the best thing to do. Also the problem may not be reproducable easily. I was thinking we could make a tool and look at the SEGV signal (or other handlers). KDE applications do this with an nice dialog which shows you the backtrace and asks you to send it. We probably don't want a dialog, but a simple call to add a debugger might be useful.

Jinmei: I think this is useful, but we didn't have enough time to do something yet.

Michal: I will create a ticket and show the code I had for this.

Stephen: Isn't this OS-dependent?

Michal: No I want to call the debugger if present.

Stephen: And this is for what? Debugging?

Michal: No, even real applications may have a debugger installed and if it is then we are in luck.

Shane: Even if it is system-specific we can look to the 80/20 rule.

Stephen: C++ does have a backtrace() call which generates a stack trace.

http://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes

Jinmei: BIND 9 uses this, but it has some limitations even on systems compiled with C++. This thing is system-dependent, but it is generally a good idea to explore this kind of thing, as long as we have time for this.

Michal: I think we should do it soon before we advertise the product too much. In the beginning there will be more crashes than later on.

TODO: Michal to create ticket for this.

Doxygen for python

Jeremy: Sent an e-mail a few days back with links to example of a doxygen run which included C++ and Python in the same report. The output was a little confusing; hard to tell which is Python and which is C++. I don't have an open question.

Jeremy: I plan on going to the doxygen community and asking them for examples of using 2 different codebases.

Michal: We could generate 2 separate, since you always know which you are using at the time. This avoids confusion.

Jelte: Probably not a bad thing to have the trees separate.

Jeremy: But we also use doxygen for higher-level documentation. But I'll find out what others are doing and point you to them.

What can we do to catch up on bug tickets?

(users hitting old reported issues.) Jeremy: Sometimes we have issues from months ago, and we research it over again. Maybe you can answer this based on new employee, or maybe we have other ideas.

Shane: We may want to increase the number of bug tickets we fix per sprint?

Jinmei: I think it's a kind of general problem that any software product can have.

Jelte: users may choose not to report bug since they see in bug queue already -- but is in backlog so continues to be ignored.

Jelte: Wonder if number of defects is increasing over time, faster or slower or...

Stephen: Maybe we should start keeping some statistics then? Look at number of open tickets classified as bugs.

Jelte: I'll see if I can put that in my summaries for sprint planning. Please remind me.

Last modified 6 years ago Last modified on Feb 15, 2012, 9:42:05 PM