BIND 10 Team Call

2011-08-09 15:00 UTC



Face to face status update


Open Day status update

Security procedure status update

Shane: Select ticket for dry run?

Jelte: We did do that, but...

Jeremy: It just got fixed.

Jelte: Better to create an artifical ticket for this.

Jeremy: At one time Michael had created a web page for ideas about Git branches for security issues. It is at

Jeremy: Create dummy situation. Document each step. One step I started doing is make it so you can't push if certain names are in a branch, like "secure", "vulnerable", or "private".

Jeremy: Another step is to have a git repo that is private that doesn't send e-mails.

Vorner: Does Trac still send e-mail if it is secure?

Jeremy: Git will send an e-mail.

Jeremy: Document steps about how to use it and who may use the secure git repo. Maybe we need to talk to other people at ISC about this. Like... do all developers have access to it?

Larissa: Other ISC projects have documentation for this. Suggest we review that and create a BIND 10 version of this.

Jeremy: Other stuff.

  • We need to make sure Trac does not send an e-mail when it has a ticket marked "sensitive".
  • We need to have something on the new ticket page saying "if you believe this is sensitive you may want to contact us in another way". (Larissa: We have an e-mail and a PGP key, there is a page on that has that stuff.)


  • Fix & check Trac first (sensitive ticket may send email)
  • Create ticket to simulate security issue
  • Create wiki page describing our process
  • Create private Git repository

vorner: Did we want to default to sensitive as on for non-developers and uncheck it later?

Shane: We discussed that but we have not implemented.

Jeremy: People often want to create a ticket and then point their peers to it. All (that we know) open source bug trackers default to public issue.

Permission for customizing trac tickets

Correcting/adding/removing components, etc.

It's inconvenient if main developers cannot make small but useful changes such as removing an obsolete component.

Jinmei: Unused components, confusing names (Packet API vs. libdns++). We sometimes find these kind of small things that might better be fixed. I thought for the current main developers we should be able to make those kinds of changes.

Shane: I think that may require admin permissions, so that's why not everyone can do it.

vorner: Maybe not everybody needs it, but perhaps if someone online at any time had permissions so we could ask on Jabber.

Jeremy: We wouldn't want all of the developers playing with the Apache configuration... this is similar but somewhat easier.

Shane: I think anyone who wants admin permissions can have them, but I don't want to give it to everyone. Partially because you don't always know when you are doing a restricted operation.

Address+port format in logs (#1086)

I'm not sure if we reached the consensus (and as far as I know the logging code is still consistent anyway), so I'm raising this again.

Shane: We only saw one non-ISC opinion: Peter Koch liked the BIND 9 way.

Jinmei: This is a preference issue. Maybe we can have a vote and decide it? Maybe e-mail would be the most effective way.

Larissa: We can use surveymonkey or doodle or something like that.

BIND 10 Expertise & Grabbing Review Tickets

Shane: people taking tickets not in the review queue. maybe they don't feel qualified to do some reviews. Like everyone to tackle reviews.

vorner: I always think if I don't understand a ticket then it might be wrong, so I ask. It probably means the code is too complicated, and it might be simplified. I have a different problem - some tickets are code tickets. There are 2 that are not for coding. 1 is already solved and does not need reviewing (msgq replacement), the other one is statistics counters. I am a developer and I have no idea what an administrator would want.

Jelte: There is the added problem of those tickets that some people have comments, but when is it officially reviewed. Then it gets stuck in there forever.

Shane: We don't have a definition of "done" for non-code work.

Larissa: We should think about that, to make sure things are getting closed out.

Jinmei: The problem of the non-code tickets looks like a different issue.

Jinmei: I think you are right, if someone has a feeling that they don't have sufficient background knowledge or expertise to review a particular patch they will probably hesitate to pick it up. I don't know if that really happens but I can imagine. I don't have any good solution for that. One possiblity is we can talk about it at the daily call. Not just saying what someone did or planned, we can also say "I tried to pick up a review request but I did not think I could do that". Then we can hopefully, gradually improve that situation through some knowledge transfer or maybe breaking down the complicated ticket or things like that.

Shane: I will probably be asking people who shy away from tickets to take them.

Jinmei: I personally think it is better if more people review more different things so everyone knows a larger part of the entire system. Initially it may be inefficient, but I think it is a necessary initial cost.

Shane: I agree.

Reviewing changelog entries

Jinmei: I noticed in some cases that changelog entries were committed to the repository without being reviewed. These are actually expected to be reviewed, in our code review guidelines.

Jeremy: Each time I do a release, I go through and read all changelog entries for the release. That might be 20 or 40. I might make small grammar fixes. I may also go back and ask the developer if we can make it better for the audience (if it is a feature).

Jeremy: Formatting-wise, I also have a script that goes through to make sure it is consistent.

Shane: Can we make that script a hook or something like that?

Jeremy: Different topic - hooks for tabs & spaces in general.

Jeremy: If it is forgotten, and changelog is added later, make sure that the git commit message explains why, like "reviewed in jabber".

Last modified 7 years ago Last modified on Aug 10, 2011, 1:09:26 PM