BIND 10 Team Call




Report of Recent Steering Committee Activity (Shane)

Shane will share some of the recent discussions and activity in the BIND 10 Steering Committee.

The committee has requested:

  • A better way of making the output of sprints visible
    • Sprint reviews
    • A quick summary of each sprint comparing expected output vs. results (3 to 4 lines)
  • A report on project risks (what can make the project fail and what are we doing about it)
  • Highlighted differences between BIND 10 plan and actual (retroactive for all of year 3)
  • Report on outreach activities for additional sponsors
  • Additional explanation of budget, including plans to address any shortfall
  • Impact of delays in overall project

Jeremy: How did these concerns come up? Seems like we met our goals in the past. Why has it been a big deal over the last 2 months?

Joao: Due to reporting; about letting people know where we are and why we are where we are. About shifting priorities, and so on. It is important when people learn things. If you tell them ahead then normally they are comfortable. If you give very little details then people start making up things in their minds. And also they hear from other people, and if the wrong idea is projected then every little thing starts accumulating. But we'll get it back into line - it is just a matter of perception really. I'm not worried, we just need to get some work done on interaction.

Jeremy: Shane your role has changed from development manager to something else.


Jeremy: Before you always had input, development-wise. But you were a constant voice, but now we've lost that aspect from you.

Jelte: I do.

Stephen: I think it is inevitable. As a rule of thumb, project management is 10% of the remaining staff. So if you have 10 people it is 100% of the time of the project management. Plus in addition there is the feature that you are not managing the team on one site. I'm not surprised Shane is spending so much time on project management tasks.

Joao: I'm not surprised either, particularly given the setup we have here. Liberating resources so they can do what they are best at is what I'll be trying to do now that my travel is over.

Joao: So you miss Shane's input... what if I were to start having opinions as well?

Jeremy: I don't know.

Joao: When I do, I will want comments to be just one more comments. Not that you feel obligated just because I say so.

Jelte: I don't want bikeshed discussions, but a bit more technical discussions would be good in general.

Larissa: Steering committee was more interested in progress on specific features in a release. If we have discussions on feature arcs that could be helpful and I can contribute on that.

Jeremy: Just for the record - I wasn't trying to be negative. :)

Jinmei: Are they concerned about the situation where not too many people are using BIND 10?

Shane: Not that I noticed. More concerned that they cannot use it.

Joao: I do have concern that not enough people are using it out there. I think the software is getting to a point where we would benefit where more people out there are trying it. I have some ideas about that which involve Larissa a lot (thought I have not talked to her about that).

Jinmei: So their concern is about the delay of our development, and status & maturity of the product in terms of what they want to do with it themselves.

Joao: Yes.

Invitation to ISC Engineering Forum (Shane)

ISC will have its monthly Engineering Forum tomorrow: 2011-11-16 21:30 UTC

ISC MeetMe? room 901. Jeremy and Jelte (hopefully) will present a few BIND 10 items to the rest of ISC. The BIND 10 team is invited.

Sprint Progress Checkpoint (Shane)

Michal: Ticket for boss configuration is important. Delayed restart. (#1342)

Shane: IXFR out not much progress? Jinmei: I think we're making good progress, but we needed to choose either boss configuration or IXFR out. So we chose boss configuration.

Jinmei: Any other thing we need to do for boss configuration? Jelte: Remove or re-implement brittle mode. (Remove is now trivial.) Jelte: Depending on how we do delayed restarts, it may be easy to implement.

What should we do for obsolete log messages? (Jinmei)

(see also #1055)

Jinmei: In some cases we find some log message not necessary any more, like as a result of refactoring. I thought our plan is to remove such old messages. Jeremy has a different opinion and wanted to keep these in message files.


  • By not removing old messages it makes sure we don't re-use it.
  • For people with multiple BIND 10 servers it might be nice to look in one place. (We might have some messages with minor changes, which might be confusing.)
  • We don't need to keep the messages file in the runtime. It could be a separate file that is only parsed & checked at configuration or some other test time.

Jelte: We had a discussion on Jabber, and I think if you try to keep a history in one document it will be confusing.

Michal: I don't like keeping them either, because we don't keep commented out code in the repository as well.

Shane: More like keeping an old API...

Jelte: You don't keep old API documentation along with your new API documentation.

Jeremy: In some cases you would, and just say the old API is deprecated.

Stephen: After a while you remove it completely.

Stephen: I think it's okay to say "if you want to look at an old message you look at the old manual".

Shane: Do we need to check for an administrator for this?

Michal: Do administrators use local copy or one on a web server?

Shane: No idea...

Stephen: I can see all sorts of problems trying to keep track of things. You'd have to know which version is associated with which message.

Jelte: I wonder if this could be generated out of Git?

AP: Larissa to talk to some administrators to find out their preferences.

Jeremy: re-use message IDs?

Shane: We never do that.

Jeremy: Then we need to keep track of old message IDs.

Jinmei: I don't think we agreed on that. We agreed that we would not use the same message ID for two different purposes in a single version.

Jelte: Exactly.

Shane: So can we never re-use a message?

Jelte: I disagree. We use names that are chosen for a reason, and if a message disappears and then is needed again, then we will want the same name and not try to come up with a forced different one.

Michal: I think we should re-use it if the message means more-or-less the same.

Jeremy: That was my point about not having different documents. If message descriptions differ slightly from each other it can be very confusing.

Shane: Maybe the right thing is to make the version number obvious.

Shane: So re-using a message ID makes sense.

Jelte: If used the same context.

Jinmei: Whether we have version 10.1 message file, and in version 10.2 message file and so on. Or whether we only have 1 web page for all messages.

Michal: I hate when documentation changes with new versions. I like the way Apache does it, with a link "newest documentation", but also links to older documentation.

Shane: I look at older versions of the BIND 9 ARM all the time.

Jeremy: Bad example. ;)

Jeremy: I am fine with that (separate documentation), but we need an automated way to make sure we're not re-using message IDs.

Shane: I think #1055 does that.

C++ comment style consistency, especially in doxygen doc (Jinmei)


Skipped for now.

How to plan statistics related tasks (Jinmei)

(I had sent a rough proposal to the team list)

To be discussed on list.

Jinmei: Want consensus before end of sprint. Will affect how we plan the next sprint substantially.

What's next for tests/lettuce? (Jeremy)

Jeremy: Goal was to have a test suite that various DNS (and DHCP) implementations can use. We don't want to get too far ahead and have to refactor it.

Shane: Maybe something to discuss tomorrow night on the engineering forum?

Jinmei: Concern of being too-specific for BIND 10?

Jeremy: Yes.

Michal: We definitely need some BIND 10-specific tests, but some can be generic.

Jelte: The problem with making generic ones is if you want to replace BIND 10 with BIND 9 is that you have completely different ways of getting the system running. That's what we need to design.

Stephen: I think that's the key. We have a pilot implementation, and this is the point where we need to step back and look at it, and what abstractions we need to make.

Jinmei: I agree. Still we don't have much time to do everything. I am also worried about trying to be too generic, and spend too much time for that. We need to find a good balance between them.

Will we consider trying behaviour-driven development (BDD) too? (Jeremy)

Jeremy: We code the higher-level tests before we code the software.

Larissa: BDD and feature-driven are related.

Shane: We kind of agreed to do this at the last face-to-face.

Larissa: I think it's a good idea. It's the right direction.

Jeremy: We're adding a chunk of time to the development. Don't know how much... 5%, 15%, 25%.

Jeremy: We don't have to do BDD, we can do feature-level tests after the fact.

Marketing -- getting one component done well and convince people (including ISC) to start using it. (Jeremy)

Jeremy: Our software has been alive for around 3 years, and we should have people using it. I think because we are focusing on so many different things, we have not made 1 thing perfect yet. If we have 1 thing that is really good people would be using it all along.

Jelte: Anything specific in mind?

Jeremy: Nothing specific... but Unbound and NSD already exist, and do a small part of what we do, but we haven't matched either of them yet.

Michal: It's because we need so much infrastructure around it. They have no message queues or configuration manager, so it is much much easier. I see the reason, and I don't know if we could have done one thing without the infrastructure first.

Jeremy: From an open source perspective, it is rare to see a project like ours.

Daily call revisit (Jinmei)

15 min earlier? or more substantial changes so all developers can join? etc

Shane's note: We have a call at 08:00 UTC and a call at 09:30 ET (USA Eastern Time, currently 14:30 UTC)

Out of time... not discussed.

Last modified 7 years ago Last modified on Nov 15, 2011, 9:05:19 PM