wiki:WeeklyMinutes20101207

Roll Call

Jeremy
Michael
Aharen
Jelte
Larissa
Stephen
Shane
Scott Mann
Likun
Ocean
Jerry
Fujiwara
Michal
Jinmei
Keith
Kambe

Greetings to Scott Mann. We have a new programmer starting at ISC in January, but he'll be joining us on the call today.

Release discussion

Jeremy rolled out a release last week. We can talk about anything related here.

Jeremy: Nothing in particular except that this was a gap from mid-September to beginning of December. Had many many changes, but very few user noticeable changes. From a marketing perspective, we've done 7 releases but each is flagged as experimental. I'm wondering if we're losing our marketing possibilities by doing this. Maybe more people would have tried things if we branded parts of it as "ready to use".

Larissa: Should we pick an upcoming release as "ready for early adopters"?

Jeremy: Maybe not the whole release but probably parts of it.

Jinmei: What do you mean by "flagged as experimental"?

Jeremy: I don't know. The whole thing is marked as experimental software so it scares anyone away from even wanting to try it. We've only seen a few people in 7 months even trying it.

Larissa: It would be interesting to see how many downloads we've seen, I can ask Dan (ISC Ops) for that. As we get to the end of the year we should push more adoption, and picking a release would be a good idea.

Jeremy: If this was not BIND and was some other server I think they would have had 100s of people giving feedback. Even if it all died off it would have gotten a lot of publicity and people trying it. But I think that's a different discussion.

Jinmei: Basically I agree. If experimental means "no so stable" I am afraid we cannot improve it until March 2011 for example. If it means "usable, interesting feature" then I completely agree with you.

Larissa: I think when we have a release when all the changes are infrastructure related it won't get the interest of beta-tester type folks. There has to be a co-ordinated effort for what is exciting to them. I think we need to look at upcoming releases and flag a couple of them.


Jeremy: I did not add documentation on the stats component for the guide for this release. Part of the stats server is there, but I was not sure how much of it was there because there was a lot that was still to be committed. We'll catch up on that.

Shane: We'll be seeing lots of commits about the stats stuff over the next few days.

Shane: FYI I have been taking the release announcement and converting to a business-friendly version.

SERVFAIL vs REFUSED: preference poll?

Jinmei: Related to thread on bind10-dev list, also related to ticket for A-Team sprint. #415. What we should return if the authoritative server cannot find anything about a query name. The current implementation returns REFUSED, and according to the comment from Evan it seems to be for compatibility with BIND 9. Some implementations return SERVFAIL. There was a discussion about this on the namedroppers mailing list. There does not seem to be any consensus and it seems to be a matter of preference. In theory server failure is the more sensible response code in that case, but many others seemingly more like REFUSED. I wonder what our team think about it.

Jelte: In effect it now returns REFUSED for compatibility with BIND 9. But the reason BIND 9 returns REFUSED is a side-effect from the way it works.

Jinmei: That's right. In the case of BIND 9 it means the client cannot use the cache, because by default in an authoritative-only server the use of cache is prohibited. In the case of BIND 10 authoritative only we don't have a cache in the first place. For compatibility doing REFUSED is okay for me.

Stephen: How important it compatibility?

Jinmei: Personally it wouldn't matter much because there are other implementations returning a different response code.

Shane: We have a slightly higher standard than non-BIND implementations.

Michael: Also difference in perception... SERVFAIL may be interpreted as server failure. What you want is a code that says "I don't have that zone". There was some discussion about putting something in the OPT record about why it failed. There are like 20,000 reasons you can get SERVFAIL.

Jelte: This may be moot, because in practice it will also almost never get that far because of ACLs.

Shane: In the usual case for authoritative servers you won't normally hit an ACL right?

Jelte: In BIND 9 you get REFUSED but that is because of an ACL. It is very hard to get BIND 9 to return the SERVFAIL, which it can, but you have to try really, really hard. If resolvers don't react differently on either it doesn't matter too much.

Jelte: I like the idea of returning REFUSED unless there is an error.

Shane: I also agree REFUSED makes more sense.

Jinmei: Seems like rough consensus. If someone has a different opinion we can discuss on the mailing list. Otherwise I'll eventually change the code to return REFUSED.

R-Team status

And a quick discussion of what the R-Team is working on so that the A-Team knows!

Stephen: The R-Team is working on using a forwarder, and also the first part of the cache. The forwarder bit has been sort of completed, although there is a certain amount of the ASIO to tidy up and the light. The changes there are pending one final review before we merge things back into the cache. For the recursive cache we've started work on the design for that. A couple of other things on the current sprint are setting things out for the logging framework. The Python logging has been done, but has been marked as experimental, the C++ logging has been done as stdout. Requirements have been done for that.

Stephen: We have started to work on the backlog of bugs. Jeremy estimated something like 15-20 bugs coming in through month. So we will try to tackle 20 bugs split between the teams. So every sprint will tackle 5 bugs from the backlog and eventually take away the backlog. I've concentrated on the R-Team because that is where my work has been focused. Maybe Jinmei wants to say a few works about the A-Team?

A-Team status

I'd like a quick discussion of what the A-Team is working on so that the R-Team knows.

Stephen: On the A-Team side the focus is on improving the performance. To that end the red/black tree structure from BIND 9 is being ported over. That is ongoing. There certainly seem to be not as many people on the A-Team as the R-Team. I'll include in this the statistics stuff that JPRS is working on.

Jinmei: At this level I don't think there is anything to add. Maybe it will be useful that we are trying to provide some usable feature, rather than implementing the various different building blocks in a single sprint. So we re-arranged the sprint tasks so that we can return a very limited feature of authoritative server for the current sprint. Hopefully in the next sprint we'll have a version of the authoritative server for the next sprint. This is partially a response to Jeremy's concern that we don't have any interesting features.

Shane: We had a discussion about breaking functionality. The idea is that refactoring may cause things to break.

Stephen: Yes, and we'll have things working by the end of the 6-week period, but we've arranged tasks into 2-week sprints.

Off-list discussions

I've been Cc'd on a few off-list discussions. I should have pushed them onto the bind10-dev list sooner, but in any case please try to keep things on-list as much as possible so we don't miss useful discussions!

how much of boost stuff we'd allow to use in public header files

Jinmei: This is part of the discussion in the review of the red/black tree branch. It specifically about boost::noncopyable header file. My understanding is that we are trying to restrict the use of boost in public header files.

Shane: That's correct.

Jinmei: OTOH Boost has many nice features of course. We are intentionally using shared_ptr in header files. This is basically a trade-off issue between wider portability and richer functionality.

Shane: Is boost:noncopyable part of the next standard?

Jinmei: I don't know.

Shane: If it is scheduled to become part of the standard then it is less scary.

Jinmei: Even if it is adopted next year for example, the availability for various compilers varies.

Michal: If we already include some of the Boost headers is there any advantage with not using the other? We need it so if we use the whole thing... actually noncopyable is only a base class with private copy constructor or something like that.

Stephen: There is the general question as to how many other packages we can use. So for example I'm considering logging, and if our requirements are leaning towards log4cxx.

Jelte: There is a difference between depending on something and having it in your own public API. Especially with Boost it has its own set of disadvantages.

Stephen: In what way?

Jelte: If you have it in your API, then you must provide those headers as well, or you cannot guarantee binary compatibility in the end. Back then we decided the features we were using are so unlikely to change that it is not a problem, but if you use more then that danger increases.

Jinmei: For Boost for example, we use other features in our implementation files. So this is specifically about defining our external API.

Shane: In the case of noncopyable it could be trivially implemented.

Jinmei: True, but how much should we implement ourselves. We could implement it by adding 2 or 3 lines per C++ class, so it is not a lot of code.

Michal: I tend to think that stuff like this is better using a comment in the documentation saying "please do not copy this because it does not work". Because you never can use a class without reading its documentation anyway.

Michael: IDE's are getting smarter and smarter... people will find the function names! Can we just call the arguments "don't copy"?

Jelte: You'd have to call the class that.

Jinmei: This is closer to the idea of using noncopyable.

Shane: Probably a good idea to document why it is not copyable.

Jinmei: We use a trick like this to detect failure at compilation time.

Shane: I think I'd prefer to use noncopyable instead of implementing it ourselves?

Stephen: I think noncopyable is clearer, but we are going to how much of the Boost library we want to implement. You've got from boost.org a downloadable implementation you can compile on multiple platforms. I see your point about hiding details from client applications, but in practice if we do change anything in BIND then everything built on top of BIND will have to change significantly as well. What I'm saying is lets use Boost 1.44 and 1.45 and that's a fundamental building block and we can use it in any manner we want.

Michal: I think that when we talk about noncopyable then noncopyable is probably much less probably to break than shared_ptr, and we use shared_ptr a lot.

Jinmei: Yeah that's probably true. So it's about the specific case as well as about the general guideline of the amount of the reliance on Boost. Whether we want to minimize it unless we absolutely need it or whether we are allowed to use it as we see useful.

Shane: Shall we just say "yes" to noncopyable and not worry about other Boost stuff? Unless people have specific stuff from Boost they want...

Stephen: We could also say we will use TR1.

Jinmei: Even if the interface is fixed the internal implementation may change and that may break binary compatibility.

Stephen: Is that a problem? We can just rebuild everything from scratch.

Jinmei: I'm not sure we're talking about the same thing. My concern is the case where we have a binary library somewhere and someone upgrades the Boost installed on the system and compiled their own program which is linked with an older version of Boost. Should we prohibit that and require rebuilding everything?

Stephen: If I've got a library and I upgrade something based on that then I am going to get binary incapability.

Jelte: Because it is header-only then you have a different set of compatibility problems.

Michael: I would suggest just say "who cares?" and let the package maintainers figure it out. That's what they do. This is a problem that every single package manager has. That's why shared libraries are versioned. If you're exposing any part of boost at all you're exposing all of it, to a certain extent.

Jinmei: That's one approach certainly, although I feel scared about that.

Michael: Nobody is installing this in a package system now, so do what is expedient, and you can revisit it later. I don't think this is so different from requiring linking against an external library.

BIND 10 meeting in January

Lets make sure we are all set up for travel.

Stephen: Someone needs to collect the dates when people are arriving to make sure the hotel is booked.

Keith: The person who will do that is the new admin, Jeniffer.

Larissa: I will see her this week so I'll speak to her about that.

Keith: It will be useful to have a list of who is arriving, when they are arriving.

Jeremy: What are the starting times and the end times?

Shane: Maybe we can start at 11:00 on Monday, with talks with 1st time face-to-face meeting attendees on Monday morning.

Jeremy: I always fly into San Jose because I always have rides. Should I use San Francisco?

Larissa: San Jose is fine.

Michael: Check prices.

Shane: bind10-team is best place to discuss face to face meeting details

Git migration status

Jeremy: Plug in for Trac called the Git plugin. It is experimental, has a lot of reported bugs. Developer has limited time.

Jeremy: Converted all data from Subversion to Git like 5 times before I realized that the version was losing information on conversion. Installing new version of Git on the box, because Debian doesn't have the new version.

Jeremy: Editing the existing content (commit logs, Wiki pages, and so on) because they reference Subversion differences. Pointed to multiple repository of Trac - Subversion for historical and Git for future stuff.

Shane: Possibly safer than doing our own markup.

Michal: Do we use integration of Subversion into Trac? It highlights ticket numbers and so on. I look in my repository and look there.

Shane: I do occasionally use it, but I don't do much development.

Jelte: Just pointing to revision numbers is what I use.

Michal: If what we gain to migrating before this is solved... would it be more or less by what we lose with Trac integration? Are we trying to solve a real problem?

Jeremy: I think some of us do use that Trac feature so we can quickly point to a revision in a Wiki message or a commit message. I've seen others use it.

Shane: Maybe we should ask the list?

Jeremy: Is the alternative to use gitweb?

Michal: No, not integrating at all. From my point of view having Subversion with integration is less good than Git without integration.

Stephen: I don't think I would miss the integration. I do make references but that is just to note the revision, rather than to provide a link to it.

Jinmei: Are we talking about Trac integration in general? [ Shane: We're talking about Trac/Subversion? integration in general. ] I personally find some of the features very useful, but as long as I can find an alternative way I'm happy with that. For example as long as I can browse the difference between two arbitrary revisions via a web browser it should be okay whether or not it is Trac.

Likun: I agree. At least there should be an easy way to provide the difference.

Shane: Maybe we should see if there is a way to disable integration to not confuse people.

Jeremy: So on the new install, disabling that we will lose context on old tickets.

Michal: They probably could be changed to the SHA1 hash from Git if it really matters.

[ Shane ends discussion due to time ]


Jeremy: More work to migrate SQLite to Postgres. There is a tool. The only goal is to give us better performance, but it might not help us at all. Other people have noted even with other database back ends.

Jeremy: The bind10 server box itself is getting a huge mix of software installed in all different places. One reason is Debian is out of date, but also installing different versions of Trac. We're using the same box for a lot of different things.

Jeremy: Finally, I'll have a very short guide to explain common Git uses for BIND 10, with some comparisons with Subversion commands.

Jeremy: We need to pick a day ... a deadline. Do we want to switch regardless of Trac? January 3?

Shane: I think we do want to do that.

Jeremy: Okay we'll start using Git the first week of January.

Shane: Can you send a mail to bind10-dev so people not on this call know?

[ Out of time... meeting over! ]

Last modified 7 years ago Last modified on Dec 7, 2010, 4:08:37 PM