ICANN - DNS-OARC workshop (from Jinmei)

"it would be good if someone can submit (and present) a paper about BIND 10. I personally don't have a promising idea of topics, but someone else may have one." Submission deadline in July. Probably a good point to start working on an idea if you have one.

BIND 10 DHCP (from Jeremy)

"Who will do reviews for DHCP? What sprints? (There is a ticket needing review but not in a sprint used by DNS developers?)"

Shane: Normally the DHCP developers will look at each others' code, but in this case they wanted feedback from the rest of the BIND 10 team.

Status update/check on security issue handling (from Jinmei)

Shane: AFAIK still pending documentation from Larissa.

Jinmei: I thought we wanted simple practice using experimental separate git repository or something?

Shane: yes, but don't we have to write down what we're doing before that?

Jinmei: It would be nicer if everything is written down, but if that is the bottleneck, then I think it is even more important to start the practice rather than waiting for that. I think we basically agreed on the idea.

Stephen: I recall Michael Graff had an idea on how to handle secure tickets.

Jelte: So then we need to set up a separate repository?

Jeremy: I was going to make a git hook to restrict some pushes. Also need to make Trac not send e-mail for sensitive tickets.

Shane: We should implement plan on next sprint to try handling one ticket as a secure ticket.

Stephen: And what is that? We need something somewhere which states what is going to be done.

Shane: I'll find this in the minutes & put on our Trac site as a separate page.

Message names (from Stephen)

"All our messages have a unique identification that will allow us to determine what the message is, even if the text has been translated into another language.

We have two styles of message names: words joined by underscores (e.g. DATASRC_CACHE_REMOVE) and word abbreviations concatenated together (e.g. RESOLVER_QUSETUP). Ideally we should decide which style we want to use and adopt it consistently."

Jeremy: I prefer spelled out.

Shane: Me too.

Stephen: I think Michal prefers words seperated by underscore.

Jinmei: Why is this important?

Stephen: It is a matter of style. You can see 2 distinct styles.

Jinmei: Consistency is important! I have no particular preference.

Message $PREFIX directive (from Stephen)

"Message files allow a $PREFIX directive to provide a string that is prepended to all messages names in the file. The original idea was that it provided a prefix added to the message symbols in a program, but that the messages logged would omit the prefix. However, some time ago we decided to include the prefix in the latter.

For this reason, I think that $PREFIX has now outlived its usefulness: it should be removed and the prefix incorporated into the message name. A second reason for getting rid of it it to help users that want to create local-language versions of the messages. A starting point for that would be a listing of all messages capable of being produced by the system. A simple "find" command can list all messages, but as the message names do not include the prefix, the process of producing a replacement file is more complicated than it need be."

Michal opposed as people may not use a prefix and we may get a name clash.

Jeremy: Can you give an example?

Stephen: DATASRC_CACHE_REMOVE... "DATASRC_" is the prefix, $PREFIX.

Jeremy: I agree we should remove it and always include it.

Michal: I am afraid people will be too lazy to type the prefix.

Jinmei: Why can we remove DATASRC_?

Stephen: Original idea is symbols in the program would have the prefix, but messages logged would omit the prefix.

Stephen: Suggest we remove it to reduce complexity.

Shane: I agree.

Comma Chameleon (from Stephen)

"A very trivial point (and I'm almost embarrassed to mention it) is removing the comma between the message code and the text of the message (e.g. "AUTH_CONFIG_CHANNEL_CREATED, configuration channel created"). Originally there to fit in with the rules of English, I now think that it will be a hindrance, e.g. when parsing syslog output."

No opposition - comma to be removed!

Message syntax (from Stephen)

"A further reflection on the message prefix. All logging output includes the name of the logger in the output (e.g. [b10-auth.datasrc]), yet all message codes also include a module identification (the AUTH_ in the example above). As we seem to be following the convention that all messages in a single module are logged by the same logger, are we duplicating information?

On the other hand, the prefix does unambiguously indicate what module raised the message. If we publish a list of modules and their associated prefixes, the descriptions would not need to include information as to what component raised the message since that could be inferred from the message code.

In addition, although we haven't done so yet, we may want loggers that cross modules; for example if we want to trace a message through the resolver, we may decide to log the trace messages - in whatever module they are raised - using a special logger. (That way we can control trace output with a single configuration.) If we do that, the prefix can be used to quickly identify the origin of the message."

Jeremy: Remove the prefix or the module identification?

Stephen: The prefix.

Michal: Prefer to keep the full version, because of searching.

Jeremy: And copy & paste... we don't want to have to guess or re-add it.

Naming of Message Files (from Stephen)

Convention to call files xyzdef.mes. Maybe call it xyz_messages.mes?

Shane: Don't like messages.mes...

Stephen: xyz_messages.mes gets processed into, ...

Jeremy: While it looks weird I agree with you. I think it's fine.

Shane: I tend to agree then, since it gets processed into other files.

Stephen: Does not need to be done in tickets. If you are doing changes in that area you can rename the file.

Effectiveness of task estimation (from Jinmei)

"We've started heavily relying on email based task estimation, and, in my observation only a small subset of developers give estimations. So the questions are:

  • is this something we should worry about?
  • if yes, should we take an action to improve the situation? Or should we simply give up the idea of task estimation practices?
  • if the answer to the second question is we should do something, what can we do?"

Stephen: I agree with Jinmei. When I get estimates it's the usual suspects.

Jinmei: I missed the very recent one myself.

Stephen: If we are going to do estimates as a group I do need feedback.

Shane: We have used them for both measuring and planning.

Stephen: Our velocity is broadly consistent.

Michal: For me the task measure of what we do over a sprint is not very interesting as a developer.

Stephen: Unfortunately it is something that is needed.

Jinmei: If most of us think it is still useful even if a smaller subset regularly provide estimates then I don't oppose that. But if we are simply doing it as a convention, then maybe we should drop that as it is merely overhead.

Jinmei: If the concensus is to continue it, I don't have any ideas to improve the situation, since as Michal says this is not an interesting task for developers.

Shane: I'm going to the RIPE NCC tomorrow and they use Scrum, so I'll ask if they have similar problems.

Jinmei: A large part of the problem is that we do it online, in an asynchronous way.

Reality check for Y3 plans (from Jinmei)

"apparently our usual optimism for the year 3 goals seems to start facing a reality check. Maybe this topic is too big for a biweekly call, but I guess it's still useful to understand where we are and briefly discuss what we should do next (or for the rest of the project year)"

Shane: I'll update the plan and send it to the list.

whether or how we use xfr for large DB-based zones (from Jinmei)

"I'd specifically be interested in comments from Shane, who has seemingly the only main developer with real world experiences in this area."

Shane: Out of time. I'll reply on-list.

Last modified 6 years ago Last modified on Jun 23, 2011, 1:21:00 PM