wiki:WeeklyMinutes20100630

Attendees

Shane
Likun 
Tingting
Jelte
Jinmei
Stephen
Jeremy
Fujiwara
Kambe
Shawn
Larissa
Evan

Action Point Issues

None.

Report from ICANN

  • Steering committee meeting (last one for .SE)
  • BIND 10 presentation to ccNSO tech day
  • One potential new sponsor
  • One probable coder donation
  • Lots of discussions about BIND 10 with technical types

2010-07-01 release

http://tinyurl.com/2e92ynh

Jeremy: Hit a few minor problems where we don't want to merge new code until the things in trunk work correctly.

Jelte: Need review for one-line fix.

Jeremy: Need to verify SOA problem is regression or not.

Shane: How did you guys find it?

Jeremy: I have a script that automates xfrin/xfrout and this found it.

Jeremy: No unit or automated test that checks for this.

Jelte: This is in ticket #262.

Evan: 3 tickets moving along but no formal "patch okay". Hotspot caching no activity in a day or two.

Jinmei: Still some concerns where we have possibility of casting incorrect data. Not 100% sure. Even if we can merge it I would suggest disable it by default.

Jeremy: Tomorrow is too late. Hoping we could have everything ready to branch within a couple hours.

Shane: A bit of a pity, but that's it.

Jeremy: We have multiple things being committed today. Too much all at the last minute.

Likun: Two tickets ready for merge.

Jeremy: Can #176 be closed?

Likun: Yes.

Jeremy: Also have a number of tickets owned by Tingting which have been merged to trunk. I will check and close those.

Jeremy: I will go through the trunk and look for command-line options and spec file changes and make sure those are updated in the documentation.

Jeremy: It does not have to be the coder updating the documentation. But some record needs to be tracked, either a ticket or whatever. Otherwise I may overlook something.

Jeremy: We have tickets which are not on this milestone which we might have overlooked.

Shane: We should talk about those when we've done this release.

Jeremy: Some of the tests appear to have errors. So the framework itself is not failing. It is possible there might be test failures that we don't get any notification for.

Jelte: At least one of them is expected to be printed now. And I think the one for the configuration manager the problem has its separate test, which should not use that directory. I'll look at the ticket when I'm done with what I'm doing right now.

Shane: How is Python testing arranged in the tree? I was using "pytest" as a target...

Jelte: For Python-specific scripts, you add a "check-local" target, which gets included in the big "make check" you run.

2010-08-12 release

Shane: Will be discussed next week. Plan on making it less bug-fixes and more oriented toward Y2 (or rather, Y2 6-month) deliverables.

Jinmei: What is the status of non-Boost Python wrapper?

Jelte: I am ready to merge. Waiting to fix the bug in trunk. If someone can review ticket #262...

Likun: I have looked but haven't tested it.

Architectural Discussion

Jinmei: I noticed in the xfr and notify parts that it uses the msgq for the communication between the auth server and xfrin process, when the auth server recieves a notify message. But when the auth server receives a NOTIFY request it sends it to xfrout using a separate Unix domain socket. I wonder which IPC is better for this kind of purpose. It might make sense to use msgq for all kinds of communications. OTOH, in general communication over msgq involves expensive string operations to it may not be good for performance-sensitive parts like the authoritative server.

Shane: With xfrout you have to use a Unix domain socket.

Likun: Yeah. I think we have talked about this topic before. We don't have another choice, because of sendmsg() to share TCP socket between different process.

Shane: I think the approach of using msgq for xfrin is appropriate since I hope we don't have too heavy a performance need.

Jinmei: We may be able to use msgq for xfrout, and send the actual file descriptor over the Unix domain socket.

Shane: Unix-domain sends all information for xfrout.

Jinmei: I think so.

Shane: I think synchronization would be heavy. You could do it simply: msgq then FD, and hope they never get out of sync. I think the current model is probably okay.

Jinmei: I don't think we can make any final decision from this short conversation, but probably a good conversation for everyone to think about.


Shane: Fujiwara-san noticed we have a lot of different types of I/O in Python. We'll talk about next week.


Jinmei: Not today, but I would like to talk about how to handle very large zones. Using some proprietary format (mmap() for example). But I don't have any concrete proposal or discussion points now.

A.O.B.

TracTimeEstimation

Mascot contest still in progress

Last modified 7 years ago Last modified on Jun 30, 2010, 3:48:53 PM