Action Point Issues

ActionPoints page is populated. Please visit to see your issues!

Mascot Contest status

Received a few applications - one nice (but with an animal already used by another project). Need more entries! MORE ENTRIES!!!

Issues for Next Release

Code freeze date? (2010-05-31 is US holiday)

Changing to Tuesday - 2010-06-01.

Hotspot cache

Evan did have time.

Evan: 1st pass done, will need to be refactored. Updating the data source to check the cache first needs to be done.

NOTIFY direct to xfrin

Feng: Cannot easily add support for XFR into b10-auth. Does not have information like IP address to send to XFR module. Currently doing quick hack for XFR, will pass information, in a branch and almost finished.

Feng: Need to modify processing interface, will do that later.

Pile of old bug tickets

See Trac roadmap for overview.

State of current reviews

Evan: Can someone take on Trac #168, which is blocking other things, like Trac #167.

Likun: Ting Ting has almost finished work for loadzone. Evan, do you have time to look at work from Ting Ting?

Evan: How soon? I have a full week planned out, which would push the hotspot cache later...

Likun: Jeremy had done some tests... I don't know... does it need to be reviewed by Evan?

Jeremy: I put comments in there, I don't think they are resolved. I haven't seen any commits since then. This is not a formal review.

Shane: I'll review the loadzone changes (NEVER DO THIS AS A PROJECT MANAGER).

Jelte: I set ticket #183 to "review" today. I still have one open review ticket. I can look at ASIO changes (#168).

Jinmei: I've looked at #168, it seems trivial, so I can have a look at that if Jelte wants.

Jelte: Was going to try to finish up the wrapper stuff today. It is quite a big change in the end. I'm not sure we can get it reviewed before next week anyway. I think I need about 2 full days to get it reviewable, which leaves 1 day to get reviewed which might be a little short.

Likun: I also created a ticket and assigned the review to you.

Jinmei: Ticket #185 ready for review.

Likun: Okay I can look at these.

Unidentified project/code for next release

Jinmei: What are you thinking about?

Jermey: Just a general question. I thought I saw some work not associated with a ticket last week.

Evan: I had started on something thinking there was a ticket, but there was not, so I created one. I thought everything had been made into tickets but only a few had been. Other than that I don't know work being done without tickets.

Jeremy: Just something if I should be prepared for something, but I guess not.

Organizing Subsequent Sprints

Ideas for goals per-sprint

Begin thinking about your personal wishlists

"Too Hard" topic: Profiling for the Auth Server

Jinemi: What I did in BIND 9 is to just run BIND 9 and feed in some sample queries, and then I basically did normal performance tests, like the one we can do with queryperf. So actually I don't know what "generic profiling" means. If that doesn't include queryperf testing then I don't know.

Shane: I guess so.

Michael: I consider things like gprof and things like that. How many times is a function called and where is the time spent?

Jinmei: Maybe what Shane actually meant is generic performance tests.

Michael: I can point to where the time is going now. The SQLite stuff. It would be interesting to benchmark the built-in zones perhaps.

Jinmei: Did Jeremy already do that?

Michael: But run queryperf against a particular built-in name, we know where the time is spent and can we make it faster.

Shane: Have people used gprof or something like it successfully?

Jeremy: Yes. In March or February, Jinmei, Jelte, and I all generated gprof reports. I think I have somewhat documented the steps, command line switches we used back then.

Likun: Have used vtune.

Jelte: I used an extension of valgrind which uses normal gprof data.

Shane: We need an automated profiling framework, and a set of zones and queries to feed them.

Michael: I have found writing a microbenchmark for a function to be useful.

Shane: Do we want to come up with a normal way of writing and preserving microbenchmarks so we don't lose them?

Jeremy: Yes, so we can know if we're losing performance.

Michael: I don't think we need to run these in an automated way for comparison.

Shane: I tend to agree.

Michael: We may choose specific key ones that we want to keep. For example, database lookup speed, which will acquire more stats and things over time.

Michael: Maybe call them "benchmark-foo" or perhaps have a benchmarks directory. As long as we don't lose them.

Jeremy: We have one... a microbenchmark committed to trunk by Jinmei already.

Jeremy: You can assign it to me, if we're going to continue on the work we did a few months ago.

Jeremy: As far as benchmarking, I've been collecting stats, just not sharing them anywhere. We have a server for that. Maybe we can get those available again in 2 weeks from now. Once we decide what is useful we can automate it.

Architectural Discussions

Jinmei: I noticed you commented about use of assert(). Is that something we would like to discuss here.

Michael: Stack trace is useful, as is something where assert() prints more information.

Jinmei: In C++ a stack trace is pretty easy.

Jinmei: Important point is whether we want behaviour of default abort.

Michael: In some cases in BIND 9 we tried to handle memory errors, but when ENOMEM comes back from the OS we sometimes don't handle that very well. From experience I say if we don't plan on that it won't be planned on. There are some situation where there is no way forward - you're given NULL when you expect a pointer.

Michael: I would propose we make a macro, so we don't have to change every line of code.

Shane: I don't know if we can ever change to exceptions because it is non-trivial.

Michael: I think we should continue with assert(). Assertions are runtime checks? They are not there with NDEBUG, right? They will probably not be compiled in - we cannot rely on them.

Jinmei: I don't have a strong preference. But I have a couple of things to consider. 1) We probably do not have to worry so much about the DoS due to exceptions. In that sense whether it is exception or assert we might be able to use it more freely. 2) In BIND 9 we have only one option: contract violation or anything exits. In C we don't have a reference, so we need more assertion checks (like for NULL pointers). In C++ the situation may be a bit better than that, since we can pass arguments by reference. And we have both exceptions and assertions - so we can use exceptions for contract violation for example. If we find serious internal inconsistency assertion might be better. By selectively using these two we might be able to handle serious error cases more correctly. These are just random thoughts about these issues, so I am not intending to conclude anything about this.

Michael: As long as we are asserting within our module, assert seems safe and as intended. I am checking my internal data for consistency. That seems like a sane way to go. Please don't assert() for things someone else controls.

Last modified 8 years ago Last modified on May 25, 2010, 4:29:43 PM