Roll Call


Git status report & issues

Shane: Any outstanding issues?

Jeremy: Had a few minor discussions on how to improve things. How to work on multiple source builds in a tree. We need to document this in the wiki.

Scott: If you have a working Git, put it in the wiki and then send an e-mail out.

Shane: Have these all been on e-mail list? Or on Jabber?

Jeremy: Both. I can look through and find them, put them on the Wiki, then ask people to review it.

Jeremy: I have some other ideas. When I move between branches I have problems because changes. There are some workarounds to create a different tree.

Stephen: There was a discussion on Git hooks - regarding commit comments. Jelte came up with some ideas. Will those be published?

Jelte: Well... I sent them to the mailing list...

Stephen: Can you put them as attachments on the wiki?

Jelte: Sure if we have a page?

Jeremy: We have Git guidelines and Git workflow.

Jelte: I'll put it somewhere.

Jelte: If you push something and local branches have changed, you get a rejection, and you need to update each branch... what am I doing wrong?

Michal: You have an old version of Git that tried to push all branches. You can grab a newer version of Git, or there is a configuration parameter. I'll look it up after the call if you remind me.

Jinmei: I have one minor thing. Whether to use the shorter version of SHA1 hash in changelog. I don't have any particular preference. I am using the shorter version, other people are not. It does not have to be consistent but I prefer consistency.

Jelte: I am one of the people using the longer one. Because I cut & paste.

Stephen: I do the same, cut & paste.

Jelte; I have no preference.

Michal: I have no preference as well, I use cut & paste. Making it shorter later is less work later if we decide to change.

Jinmei: That sounds like it makes sense to me.

Michal: Once we decide we can change it.

Shane: It sounds like most people use the long version. That makes sense to me because even with the short version you're not likely to type in by hand.

Shane: Can you send to list?

Jinmei: I don't know if it's a big issue but I will.

Scott: Maybe that can go on the Wiki?

Michal: On the changelog page?

Jeremy/Scott?: Yes.

Jinmei: Okay I'll do it.

Atlantic/Pacific daily call evaluation

Stephen: I think the Atlantic call is going quite well.

Larissa: The challenge with the Pacific call is the International Date Line. It is also difficult for Asian colleagues when they have been at the BIND 10 call or the Sprint Planning call the night before they are not at the office at 09:00.

Shane: Improvements? Or...?

Larissa: My personal feeling is to leave it for a couple more weeks and see. The call does happen a lot more as with the old system, but I do not think it is as effective as the other call. Also because of the date line issue we don't have everyone every day.

Jeremy: Maybe if everyone suggests the best time that works for them? Having late night/early morning calls... we didn't think about that.

Larissa: Feng brought it up (he's not here)... there's always someone from CNNIC there but not everyone.

Shane: I'll send a mail asking for good times...

Larissa: Shouldn't we wait until the end of the Chinese new year holiday?

Shane: Okay, then we'll have to wait at least 4 weeks. Okay!

Report from last release

Jeremy: We had feedback from one person who tried the release. They noticed a couple of problems, and I replied to their e-mail on the list. Some of their problems are already fixed in a branch or two that Jelte has, but not merged into master yet. A couple problems had to do with documentation.

Jinmei: Where did you get that? I did not see it?

Jelte: Cathy on the list, right?

Jeremy: Yeah.

Jeremy: We need to get more feedback. That's one thing to be sure. Whether specifically asking people one-on-one.

Jinmei: Do we know how many tarballs have been downloaded, for example?

Jeremy: I'll see if I can find out.

Jinmei: I sometimes notice that there can be regressions that cannot be caught by unit tests, so it would be better if we could have system-level tests, even if it is simple, before the next release. Like the problem found in msgq for example, that could stop BIND 10 starting, but we could not find it from normal unit tests. So if we have a single script to start & stop BIND 10 even that simple test would be helpful.

Shane: Agreed.

Jeremy: I have a shell script that I run that runs loadzone, starts up, does some queries, does a zone transfer, then shuts down with bindctl. It uses a few of the components. The cmdctl password management tool has not been used, I opened a ticket for that. Simple fix but nobody uses it so nobody noticed!

Shane: I run this for my server, and it is the best so far.

Jeremy: I've been using the forwarder for over a month and a half on my primary systems at home.

Michal: Maybe we could put a message at the end of the configure script asking for some feedback? I am not sure I noticed, but I think there is not one. If people test out manually there is a chance they would see it.

Shane: I think it makes sense. Can you open a ticket?

Michal: Yes.

Jeremy: For the next snapshot release... in 4.5 or 5 weeks. We have a date but I can't remember off the top of my head.

Apache Portable Runtime library and apr-util library dependency

Jeremy: How many dependencies we want to require? If there are dependencies that might provide duplicate features... in this case we require log4cxx. One is Apache Portable Runtime library. Simple... runtime equivalents for different operating systems. The other library is apr-util, it provides various functions like SHA1 algorithms, user ID algorithms. All sort of routines we already have. If we're going to start using these libraries, we could just use Apache to implement DNS. ;)

Jeremy: Related to this is for the Boost libraries themselves, to add option parsing for example. Also we need to consider... Python is already big, we know that. But we don't need everything to be big for embedded systems. We need to figure out what our sweet spot is, or how big we want to get. I can imagine we get dependencies from numerous places. For a while we said "no Boost libraries" for example, and the only other dependency we introduced was the Python process rewriting (which could be turned on and off, so on several build systems I disable that feature).

Stephen: A question we really want to ask is "how much do we really want to reinvent the wheel?"

Michal: I think this is more like a marketing decision. It sounds worse if it has more dependencies, but it is more easily written and cheaper. I don't know if asking the programmers is the way to go. For myself, I would say having more dependencies is easier to me, but I don't see the customers who need to run it. I think if you have a TLD then having to compile Boost is not much of a problem, but that is not everywhere people will be running.

Shane: I suspect most people will be using whatever package their system provides.

Michal: I don't like using Open Office, because it takes a long time to compile and takes a lot of memory for example. So there is a line but I don't know it. How many people use a Pentium II in their house, and if they are relevant to the ISC marketing model or not?

Jinmei: See ticket #528. boost::program_options and in general. In the case of Boost it is quite different. It is more about to use the compiled binary version of Boost or not. As long as we use the header-only version then it is a totally different matter from what we discussed here.

Shane: So is boost::program_options header only?

Scott: I think it is.

Jinmei: I tried it several months ago and I needed some library.

Scott: I'll re-check.

Shane: We had the same issue with ASIO for example. That's why we don't use boost::asio for example.

Jinmei: One aspect is the availability of the dependant libraries. The compile time or memory may matter. But the minimum requirement is whether the libraries are available on the popular package systems or different operating systems. Maybe if we had a summary table somewhere on the wiki that might be useful.

Jinmei: Unlike other user-level applications, name servers may be considered core part of operating systems and may be considered separately from more advanced applications like browsers or things like that. In that sense minimal dependencies may be more important than duplication. This might be an issue if we want to provide part of the core package to an operating system. I don't have any suggestions about that. It is a trade-off issue and some people will have a different opinion.

Jeremy: Historically the BIND name... and it is possible we won't have that association with Berkeley distributions any more.

Larissa: Do you mean if we have dependencies it would alter that?

Jeremy: Definitely. They have a core. It's not all BSD licensed, but almost all. And the dependencies are things that are BSD-licensed or compatible. Secondly they don't want to bring a lot of dependencies into their core operating system. There has been a big effort to strip it down and make it more lean. It will be interesting that the Berkeley name server won't be included in the Berkeley operating systems.

Jelte: Regardless of the other dependencies, this would already fall with Python, right?

Jeremy: It is possible that the Python modules would be installed through the ports system?

Jelte: So we would run without Python or write again?

Jeremy: I think we would have to target the embedded and the BSDs the same way.

Stephen: It sounds as though we are undecided about the level of dependencies we want. Is that right?

[ agreement ]

Stephen: The logging has not been committed. In any case all it does now is log to the screen. I can change it to take out log4cxx and only write to screen. We can defer the choice of the underlying logging system until later.

Michal: Or we can use log4cxx now and if we find out the dependencies are too high we can change it later.

Stephen: There is a task to make the link between the logging and log4cxx less tight than it currently is.

Jinmei: Does that have any intermediate layer? So we can change?

Stephen: Yes.

Jinmei: In that case we can just go with log4cxx for now.

Shane: I'm inclined to agree because that is the least amount of work.

Shane: Something to discuss with Larissa and me?

Larissa: This is a product issue so we need to discuss.

BIND 10 face to face in Prague

Shane: We will meet before the IETF in Prague. I'll send mail.

Jeremy: If anyone has experience going to Prague send it.

Y3 Scope of Work

Shane: Sent to list..

BIND 10 authoritative performance that is, concrete definition of "BIND 9 equivalent" regarding the b10-auth performance. (This is an auth server specific topic and may not be appropriate for the bi-weekly call, though)

Jinmei: Confused and want to know the concrete requirement. If we can make it 10% faster, is that sufficient? OTOH, if we need 2x fast as it currently is, then such micro-optimizations are not helpful and we need to think about more drastic changes. Without this high-level goal discussion each optimization proposal does not make sense to me. I am specifically talking about the Y2 contract thing.

[ Shane explains motivations ]

Michal: I suggest we put low priority on performance compared to other tasks and leave them out compared to bugs and functionality tasks. Not as important as the other stuff.

Any Other Business

Out of time!

Michal wonders about his hook proposal.

Last modified 7 years ago Last modified on Feb 1, 2011, 4:04:44 PM