wiki:WeeklyMinutes20100225

Notes from the BIND 10 call.

Attendees

Likun
Michael
Jeremy
Shawn
Larissa
Jelte
Shane
Kambe-san
Fujiwara-san
Hankins
Jinmei
Evan

AP from previous weeks

Jeremy to set up automated coverage testing

Shane: keep this as an action point?

Jeremy: done for weeks

Jeremy to update blog article to include directory moves and publish it

Jeremy: not done yet

Jeremy to rearrange the Subversion tree

Jeremy: Done, in an experimental branch. Evan looked at it.

Shane to talk to Jeremy about releng checklist

Shane: Done.

Shane to try to get logging for Jabber

Shane: Jim (Ops manager) said this is a good idea he would talk to the Ops team about doing this.

Jabber alternatives

Jinmei: The trouble I'm currently having with Jabber is that it only has a very short memory. It's also a mix of various kinds of information. Greetings, deeper discussion, and so on, without any subject line or context or threads. So it is difficult to find important information there. With the current use of jabber I don't think we can solve these kinds of issues. No specific alternative, but at least we need to reconsider how to use it.

Jinmei: One attempt to address these issues, is that I'm attempting to move a particular part of chats to Trac tickets or BIND 10 dev list. Doing something on Jabber first and then copying important context to the web or to some documentation file in the repository will not work, in my opinion, because it is very easy to forget things like that. I think we need a first class place to maintain these kinds of information.

Michael: No matter how you look at it, this is a social issue. If there is a discussion in Jabber, then it should be posted to the list. I think we're doing this fairly well.

Jinmei: I don't think so!

Shane: I did spend about a half hour going through the history this morning, and I know I missed something!

Michael: Jabber is not a replacement for e-mail. It's meant to be like a water cooler effect. The discussion about class naming was perfectly fine. It's up to Jinmei to decide what to do with that.

Evan: I agree. I'm not sure an action point came out of that. It resulted in a vague plan to change one of the names... if that happens that's fine, if it doesn't happen that's not a great loss. It was not a significant discussion, we might have discussed it over lunch if we were at 950. I think Jabber is a replacement for sitting around the table at 950, not a replacement for bind10-dev, but good when bind10-dev is too formal. I feel pretty comfortable with Jabber, and I have a jabber window always open on my desktop.

Jinmei: To me, the conversation about syntax is already beyond the scope of jabber chatting. I understand others may think otherwise. I tend to agree that the mailing list is not a good place for this kind of relatively minor thing, but the volume of the conversation is beyond the level of jabber chatting I think.

Michael: We are using jabber as a replacement for me walking into your office to talk to you about something. If it results in something that needs to be done, then a ticket or something needs to be created. I think what happened is exactly what should have happened.

Jinmei: I won't have the context that leads to the conclusion.

Michael: I tend to agree, but if I walk into your office you won't have that context anyway. This is my concern with logging jabber... if we log jabber we would all be reading jabber logs, because we all HAVE TO KNOW. Jabber should not be treated as a journal - when you're there you participate but if you're not there you miss things. I don't see any problem at all with the way jabber is being used right now.

Jinmei: Probably just a difference of opinion. I'm pretty sure that in the future, not too long from know, we'll want to know why we made that decision. But if we lose the context of the conversation, then we can only rely on a person's memory.

Michael: Then whenever this is converted to e-mail or whatever, that context should be included. (Jelte: Or a summary.)

Jinmei: In theory this will work, but IMHO this won't work in practice.

Michael: I can't think of any other tool out there which can do this, other than moving all conversation to e-mail (which I am fine with).

Jinmei: Jabber channel is still a useful tool for asking for a quick review or for very quick questions.

Evan: I would not be fine with moving all discussion to e-mail. I think that would be a large waste of time. E-mail takes a lot more thought and effort than jabber. It takes me half an hour to write an e-mail, or 10 seconds to write a jabber.

Jinmei: Technically our jabber channel is not closed...

Evan: But you can see who is there.

Jinmei: I'm not arguing that everything will be discussed in the mailing list. What I want to get is to keep the record. Some nice way so I can understand the context from the mix of information.

Michael: I'm not concerned with the context as the summary of the context.

Evan: I've had conversations that ended up with a Trac ticket, or a vague plan that didn't involve a Trac ticket. In any case, we need scope for informal rapid questions that I might be embarrassed to type in e-mail.

Jinmei: I'm not denying the need for rapid conversation. But our current use is beyond that level. Maybe we just have different preference or opinion. I'd like to propose a compromise: I prefer e-mail or Trac or something recordable. If others are happy with the current use of Jabber, please continue to do so, but please also allow me to move any part of it to e-mail when I think it is beyond the scope of conversation.

Michael & Evan: that is perfectly fine

Jinmei: I would like, maybe Shane, to watch and copy the decision & action points to e-mail or whatever and letting us know if context is missing.

Shane: What you're looking for is that when things get moved out of jabber that they are self-contained?

Jinmei: It should contain sufficient context that the reasons are included, and not just the conclusion. Someone should be watching this, and notify of missing information.

Michael: I think we're adding a lot of process to a lightweight forum.

Evan: Furthermore if it's a discussion between Michael & me then I would be the best person to ask about the context.

Jelte: Anyone who wasn't could also see there is no context and see that.


Evan: Is the web site the only way to make a ticket or can I e-mail them in?

Michael: I recommend the web site.

Shane: There is probably a trac plugin somewhere.

Jelte: The e-mail plugin is not enabled.

Michael: I wish login would take you to https though!


Shane: I do not want to create a process for reviewing stuff that comes out of jabber. If we discover in a few months that we are missing context from previous jabber decisions, we can revisit that decision.

Jinmei: One thing I'm not sure from this topic. If I understand it correctly, Michael disagreed that we should have longer or permanent logs from jabber chat.

Michael: I am concerned that it will cause a distraction rather than increase usefulness.

Jinmei: I don't think having a longer log makes it work.

Michael: I don't either, and I think we need them. Don't expect me to go back through every 24 hours!

Jinmei: I don't expect that! The reason I want them is for backup from previous conversations.


Evan: if we're going to have logging does it have to be open to the public?

Shane: my plan was not to...

Evan: I'm not happy about the bind10 conference room being open to the public...

Y1 deliverable status

Shane: authsrv answers everything but NSEC3?

Jinmei: and AXFR

Evan: It does everything I can think of. I also wrote a zone loading tool in Python, which will need further work but it does the job for now, injecting into SQLite3 file. A little bit of the work has been reviewed... Jinmei pointed out that I had no unit tests, so I am backfilling that now. I hope to have a vague attempt at unit test code today. Have queries that can be fed into doQuery() routine.

Likun: Feng is working on Python API planning on finishing the wrap the API that XFR-in and XFR-out will use, due to time problems. Another girl from CNNIC is working on XFR-out, and her requirements were finished today. XFR-in has not received too much work, but plan on starting to do that tomorrow. Time is quite short.

Michael: one question we may get is, "why SQLite3 for the database?"

Shane: Why did we choose SQLite3?

Michael: because it was one of the harder ones to do?

Evan: Also BDB doesn't support DNSSEC.

Michael: we know we need a non-in-memory format. Maybe we want a blog post about that?

Shane: Excellent idea, thanks for volunteering.

AP Michael to write blog entry about SQLite3.

Likun: Maybe easier to manage with SQLite3.

Jinmei: I don't know the status of TSIG. I don't know the plan for implementing in the year 1 release. I don't think we can implement it in C++ for year 1.

Michael: technically an authoritative server is supposed to handle TSIG if we say we handle it (generically)

Jinmei: My question is whether we need this for the Y1 version. We certainly need it in the C++ library. The point is the release timing.

Shane: if we have to have it for all queries (SOA check, NOTIFY) then we need C++, so TSIG simply is not possible

Shane: if we don't have time, we don't have time, so we will put it on the list for Y2.

Jinmei: What we should do in these 2 weeks. Is C++ TSIG included in that? If the answer is "yes", we need to think about dropping some other feature.

Michael: Do we have a list of things we want/need for Y1?

Shane: Yes. NSEC3 support. EDNS0 support. XFR-in. XFR-out. We also have work connecting things together to make a finished product. For example, configuring the location of the SQLite3 database. And verbosity and prints.

Evan: And it might be useful if we configure the SQL database on a memory database for speed.

Jeremy: Does the authoritative server handle simultaneous requests?

Michael: It is single-threaded.

Jinmei: I don't understand the question.

Jeremy: It was brought up before so I am bringing it up again.

Michael: Do we support TCP now?

Jinmei: I don't think we support it. It's not an RFC yet so we're okay.

Jeremy: The next thing is documentation. I want to talk to Evan who can show me how to start it up and how to configure it, so I can document that. I've only been running the stuff in trunk.

Evan: There's not very much to tell you yet.

Jeremy: Once I know what has to be run to do it, I was going to run it on the benchmark server just to see what the performance and resource usage was.

Jeremy: Something for our deliverable needs to have the debugging and print statements.

Jelte: Yes, those all need to go.

Evan: I see some ugly lines, but not hundreds. It doesn't keep spouting output as it runs.

Jeremy: I've been using "--verbose", and they all randomly output some debugging output.

Jinmei: Are things like NSEC3 and EDNS0 things that we need to implement in year 1.

Evan: I heard them as things we need for Y1 that we have not done yet.

Shane: EDN0 is a must. I think NSEC3 is possible, so we should do it.

Evan: We're not going to do TSIG at all?

Jinmei: My understanding is that we should support it for AXFR, but I wasn't sure about normal queries.

Evan: Maybe TSIG is a better use of time than NSEC3?

Shane: possibly... probably true... we can aim for TSIG instead of NSEC3... Michael to do this?

Michael: let me take a stab at that and see how it goes

Michael: at the very least I can write the classes I need and tests for it

Michael: How long will NSEC3 take?

Evan: I haven't sized it yet. We need to figure out how to include the hash functions (include OpenSSL?), I wouldn't expect it to be very long time, but I don't know how long the unit tests would take.

Jinmei: note also that we need base32 added for encoding and decoding for NSEC3

Jinmei: I'm afraid TCP support might be critical, if we want to support DNSSEC. I'm wondering if we support the ability to truncate a message in a response that means we will get TCP requests after that. If we really don't support TCP for Y1 deliverable we can't truncate the message anyway.

Michael: I think we should take the feature set we have right now, and declare "this is done".

Jinmei: I agree.

Shawn: You might want to set it up into a branch. You can continue adding new code.

Jelte: How hard is TCP?

Evan: I think with Boost's asio this is pretty easy.

Shane: we need to pick a date for "feature freeze".

AP Shane will pick a date for the feature freeze Friday

"Reviewed" branch

Shane: we have reviewed code now, so we need a branch for this

Jinmei: reviewed branch should be created too now. I don't think there is any blocking issue for this.

Jeremy: I think we can do this once we decide on the layout, which is the next discussion. Once we have that I can start putting in the reviewed code.

Evan: I really like the layout Jeremy sent yesterday.

Michael: me too

Jinmei: if I don't answer in time please go ahead

Jelte: I'm assuming the cpp directories that are in there are supposed to be gone. But I'm fine with it.

Jelte: Is the base Python module ISC or BIND10?

Shane: Are we using isc in C++?

All: yes

Shane: Then lets use isc in Python.

Evan: It doesn't have to be isc, it can be bind10 or b10.

Pending code reviews

AP Shane to update the review process so that if you want someone to look at it you are no longer the owner.

Shane: Anyone waiting on someone to review code?

Evan: I have a whole bunch of reviews for ticket 50.

Jelte: Going to put up 2 or 3 tomorrow.

Jinmei: Have been waiting on review for rdata stuff, ticket 48.

Likun: Will make the c&c and bindctl to be reviewed tomorrow.

Shane: My algorithm is: I go to the tickets and make sure someone owns them all.

Evan: I have been confused a number of times from open tickets. Does anybody know Trac?

Jeremy: I do a little bit.

Jinmei: I have a question. I tried to make the owner to someone else other than me. Can we do this to an anonymous person?

Shane: You can leave it blank...

Evan: What if we have a special account to indicate "this is pending review" and you can put a name in?

Jeremy: There is a keyword field, and I have been putting "Review" in the keyword field.

Tree shuffling v4.0

Include files

Test coverage

Python location

Jelte: sick of discussing them, one final question to Jabber room

Shane: tests in their own directory so we don't test the coverage of the test code

CeBIT next week (Shane & Jelte)

Shane: Will try to have call next week for CeBIT

Y2 status

Shane: Norm Ritchie has been getting agreements from the current sponsors for Y2. We have many though not all.

Next face-to-face meeting (first for Y2)

Shane: It is not certain, but it looks like the next face-to-face meeting will be in Beijing, in the last week of April.

Michael: Do we need visas?

Larissa: ISC can help sort this out.

Last modified 8 years ago Last modified on Feb 25, 2010, 4:50:14 PM