BIND 10 Team Call




Meeting Time

Meeting earlier was originally for release review. Does it make sense?

Jinmei: Original intention was only for release only, rather than every bi-weekly call. Will be harder after time changes (06:30 vs. 07:30).

Release Review

Jeremy reports... Tarball not shipped yet. Some issues:

  • Missing some changelog entries (for significant new features)
    • New logging infrastructure
    • Also for dummy DHCP
  • Some .spec files updated without documentation for those changes (will create tickets)
    • Have a script to catch these, maybe run periodically instead of immediately before release
  • Still has issue with ISC log directory (move from Python to C++ logging). Michal: could pick another name, but we want problems so that we can fix them now. Jelte: Can we fix in build somehow? Jinmei: I have a proposal and gave the ticket to Jeremy. Kind of hack... checks via Makefile, prints warning, stops install.
  • xfrout got new logging framework, but still has all of the logging. Michal: Does not have logging... probably has some statements left which do not do anything. Jeremy: I don't know what the behavior is. There is a ticket for this.

Shane: Has extending release time helped? Jeremy: Don't know. Branch built without any errors!

Adding Unplanned Tickets to Sprint Shane gives background (in e-mail).

Jelte: In this case I didn't mind since it was so small.

Stephen: That is relevant. Adding tickets moves the estimated completion date. However for very, very small tickets it is more convenient to do it there. It must be done on a case-by-case basis. For sprint planning, we're not doing it "by the book". We are not going to complete all the tickets in our 2-week period.

Michal: I think a small ticket is easier and improves morale by solving problems 2 hours after reporting.

Stephen: Reason we have "new tickets" and "next sprint proposed" is to make sure tickets are reviewed before included.

Michal: This was a bug report for sure. I don't mean new ideas. If it's a bug report that can be solved in 2 hours it kind of makes us developers think "hey we are good!"

Shane: I am kind of okay with this, but should it be announced somewhere?

Jelte: In general it should be in backlog or next-sprint-proposed. Putting it in the current should be exception not the rule.

Stephen: I agree. It should go in the jabber room, so there is some review.

Shane: We can negotiate in the jabber room, but not everyone will be on the jabber at all times. Should we announce to bind10-dev?

Michal: Small tickets should have limited bureaucracy.

Shane: So put a note in the ticket itself perhaps.

Jinmei: It may help if we count the number of such tickets after each sprint. Then we can see if people are behaving reasonably, and whether we can forget it or not.

Unshipped Tools

Michal: Tools are in git but not tarball.

Shane: BIND 9 had tools not shipped, and it was annoying.

Jinmei: In BIND 9 the repository is closed. BIND 10, people can get access to the repository so the analogy does not apply.

Jelte: Also need to make it clear what is needed to build and what is needed to run it.

Jeremy: I think we should ship it all in the tarball. The tools directory should say "this software is not installed, it is just used to suppliment builds, and has not been reviewed".

Stephen: If you're shipping code, and it breaks, people will still look to you to fix it. So we need proper unit tests, reviews, and so forth.

Michal: I don't think so. We don't have tests for tests, for example. If the tests are broken it is visible and we need to fix it. If a tool is broken and it does not work for us then we need to fix it.

Shane: We could say "there are a bunch more tools that you need to get via Git".

Jinmei: Most people don't care anyway.

Michal: And most developers don't mind if it breaks.

Jeremy: There is a tool included in Git but not shipped in tarball used to help documentation. Because the tools is not shipped we also ship XML and HTML. So the tarball provides duplicate docs.

Shane: I think we should include them.

Stephen: Are going to retro-fit tests?

Shane: I think the disclaimer is enough.

Consistent Naming for Component/Module/Configuration/Logging/…

Jeremy: We had a discussion about boss, which is referenced different ways (in logging, bindctl, and so on). Do we want to be more consistent?

Shane: Goal is to be easy on users.

Jeremy: And easy on developers!

Michal: I think consistent names, capitalizations and so on, is good. The boss is slightly different because the executable should be called "bind10". Otherwise as little aliases and things is good.

Shane: Is this (boss) the only place?

Jelte: The running binary is b10-xxx, but in the configuration it is Xxx (which we need to change anyway).

Michal: The logging is without the b10?

Jelte: The same as the binary name.

Jinmei: I think the cc module has some non-trivial things. Sometimes it is called 'configuration module'.

Michal: There are 2 configuration things. The cc, which is the link, and the configuration manager. So it might be confusing.

Jinmei: Another thing is the msgq. First of all we may replace it soon, then I don't know if we call it the message queue. Even if we do not replace it, it is called differently in different contexts. msgq/message bus/...

Jelte: Was mostly about the name of things themselves, not the documentation.

Jelte: Suggestion for boss is to call it b10-boss and have a 1-line script that execs the boss. Also helps "ps".

Shane: So we would rename the directory, spec files, ...

Shane: Might be slightly confusing if you run "bind10" and you get "b10-boss" in your process list.

Jelte: Or we could not "exec".

Jelte: Other step would be to uncapitalize all the module names in the spec files, and make configuration there case-insensitive. May be harder if we want to do it for all identifiers...

Jinmei: What about other programs that are not daemons? Should we use the b10- prefix for them.

Shane: We picked b10- so administrators would not be confused. We could pick a different prefix for non-daemon programs.

Jinmei: I think the motivation is good. I don't have a strong opinion or preference for the specific proposal.

Shane: Okay, 3 tickets then.

  • bind10 -> b10-boss
  • de-capitalize 1st letter in module name
  • make bindctl case-insensitive

Jeremy: "boss" might be confusing

Security Procedure Status

Jeremy: No changes for git push hook. Maybe this should be a ticket?

Address+Port format in Logs

Jeremy: Also for documentation?

Jinmei: I used BIND 9 style, address # port:

I am okay using a different style.

OTOH it might be nice to provide BIND 9 compatibility in logging.

Stephen: When I output address/port I use the port in parenthesis:

No strong preference but we should be consistent.

Shane: I like the colon style.

Jelte: My software uses colon notation, but always includes square brackets.

Jinmei: I think actually it follows some RFC.

Jelte: I saw one RFC mentions it, but only as "this is what is usually used", not "this is what you should use". RFC was about IPv6 transition.

pound sign ->£ #<- octothorp

Stephen: We can defer, but it looks better if we are consistent. Also, how do we express a name and an RRTYPE and an RRCLASS. Do we use ""?

Jinmei: I think this is largely a preference issue. I am okay the approach that Shane just explained or having a quick vote on the mailing list or something.

Shane: I guess we can bring it to the mailing list. My defaut preference would be to use URL-style if there is no consensus on the list. But we'll see how it goes.

Wiki Design Page Freshness (vs. doxygen)

Jinmei: Not sure if it was a ticket or Jabber discussion. But I remember something about whether we should update the design wiki page when we change that as a result of implementation. Normally we propose something, initial design on Wiki, then when we start the development the details often change. The question is whether we should keep the original wiki page updated, or maybe we should document in the source code (for example).

Michal: I don't like documentation of the source code or design in the wiki. The source code will have multiple versions, which may have different designs. The wiki only supports one version. People either always need to update to the newest version or they don't have the documentation. I would like documentation to live together with the code. OTOH, leaving outdated documentation on the wiki doesn't sound good, so I propose we delete the page instead of leaving it outdated.

Shane: We would put a pointer to some other documentation?

Stephen: The wiki does support multiple versions. The thing I worry about documenting in the source code is people won't document the overall design. Doxygen does allow you to put design and additional text in the system. If you look at the current doxygen, there is the "related pages". I added a few for "data scrubbing" in the logging API. I have no worries about putting the documentation in doxygen, but we do need these overview pages.

Shane: I agree.

Michal: If we put it into doxygen or not, if we put it in the source, then whoever changes the design is reminded to update.

Jinmei: I don't think anyone is proposing having just method descriptions as sufficient. The question is, where we keep the updated document for the entire design.

Stephen: I'm quite happy to have it in doxygen, although I don't know how you get images in doxygen. There would be a transcription process moving from the wiki to the doxygen documentation.

Michal: Or we could put the doxygen document as the initial document. We could do the updates and discussion in this way.

Shane: So do we agree that design should be in the code, in doxygen?

Stephen: I'm happy with it but we need tasks to move what we have into doxygen.

Jeremy: I prefer it in the source tree also.

Shane: So it sounds like we need to move some of our documentation then.

Jeremy: Also docs flow together in doxygen. Finding things are hard on the wiki.

Shane: How do we present the doxygen on the wiki?

Jeremy: Right before or after a release I update the docs served on the web server.

Jeremy: One negative issue. A very minor mistake may cause the documentation not to be generated in HTML. It may not be noticed because output is so verbose.

Jinmei: Should we try to fix doxygen warnings? I see many ones.

Jeremy: I do that periodically. It is pretty time consuming.

Jinmei: I wonder whether the cost is worth the benefit.

Jeremy: It is needed.

Shane: Can we automate checks for warnings, and make them like C++ warnings?

Jeremy: Yes, although understanding them is sometimes difficult.

Shane: I'll look through the wiki and send a list of design documents to the dev list. Then we can discuss and make tickets as appropriate.

Jeremy: I mentioned I can make a check to find missing documentation, but it is part of our review process, so we should consider somehow improving that.

Shane: I think the best thing is if you notice any part of the review process not being done, please remind the reviewer and the original developer.

Last modified 7 years ago Last modified on Jul 6, 2011, 10:39:22 AM