BIND 10 Team Call




Release Review

Originally scheduled for Thursday, but Thursday/Friday was US holiday.
Wednesday did branching.
Yesterday Jelte & Shane provided 2 bug fixes that we had time to add into. BR ? Release-related problems:

  • Waiting for signers
  • Uploading to FTP

Not sure who signers are! Should get changed so Shane has signing key Real Soon Now.
Some idea to normalize release process for all ISC products.

Release did not match exactly with latest sprint. Could have done release on Wednesday, but that is end of DHCP sprint. Was not sure if DHCP would have anything. Tarball did include significant DHCP changes and improvements; but no way to test this (e.g. no way to start the server, and no documentation for this sort of thing).

Should have separate announcement for BIND 10 DHCP.
Stephen: Reason not highlighted is that functionality is so limited now.
Jeremy: Some hackers might be interested in library, for example. Better not to wait for functional server.
Will create some tickets based on things seen.

Removal/Consolidation of Environment Variables

I have a potential topic; discuss an approach to the removal and/or consolidation of environment variables, and possibly the slightly related generated python files and scripts.
Came up for ticket #1292
Possible solution: change .spec files on installation.
Jinmei: Depends on how tricky it is.
Another possible solution: If default then change it if running in-tree. But this leads to unexpected results.

Related to how we use run scripts and generated Python files. Same base cause...mostly.
1st identify places we use these, then suggest approach for consolidation (and removal if possible). Then implement that. Jeremy: Looked at this several months ago, so starting point:

Jinmei: Essential problem is things added in ad-hoc manner to solve specific issues.

Proposal: Create ticket in next-sprint-proposed to take Jeremy's mail and update it, and create 1 or more tickets to implement it.

Daily call revisit

(left over from last call) Michal: I proposed we could move the call 15 minutes earlier, because on some Tuesdays & Fridays I cannot attend the call because school starts at the time when the call is. But now there is 1/2 month before Christmas and then 1/2 month after Christmas and then the time table changes for me. Jinmei: I talked about the crazy idea of changing the call time every month or so for some particular period. Point is to use 2 (or 3) times so at least 1 time is attendable for everyone.

Jinmei: Maybe try a doodle poll?

Shane: Will set that up and send link to team list.

C++ comment-style consistency


We use /// and // and /** for doxygen comments, and it is inconsistent.

vorner: I prefer /** */,as vim is able re-wrap lines and close/open them.
Jelte: No need to change existing comments, but we should have a standard, and I don't care which one we choose.
Jinmei: Slightly prefer making it consistent. No preference either style. Same points apply to other comments - not only Doxygen style C++ comments!
Stephen: Prefer to use existing style and not add a new style, for existing files. Prefer /// for this.

Jinmei: We can do a poll for this and pick up the preferred one.
Jeremy: Can look at existing code and see what most common one is.
Jinmei: That might give us historical reasons.

Shane: Will put together another doodle poll for this, and send to bind10-dev.

Jinmei: Sometimes we must use a particular style. (So sometimes we cannot use ///, for example.) In that case we explain why we used an inconsistent style for that particular part of the code.

DDNS discussion / receptionist (from bind10-dev)


Jeremy: Do we have requirements for receptionist? No.

TODO: Ticket to document receptionist requirements.

NSEC3 task(s)

Stephen: Have created tasks for authoritative server. Do we need this for resolver? (If not can close #1178)
All are in new tasks milestone. (Shane: now in next-sprint-proposed)

What should we do for obsolete log messages? (see also #1055)
Larissa has sent lots of e-mails to many users, and gotten no feedback. Probably okay to decide without outside input. Larissa will ask for more input.

Jinmei: Will become more important later in development.

Data Source names

Move data source library objects into another directory, one suggestion uses "module". We use it for Python modules, and our daemons are modules, and these dlopen() data source objects are also modules now.
Jeremy: suggest "plugin".
Michal: suggest "backend".
Jelte: "plugin" is probably not good...
Jinmei: (about "backend") we may want to use this same place for other extensions. I have no strong preference.
Jelte: will use "loadable backend library". LBL?

Interface Design Discussions

Jeremey: We need to have discussion up front. For example configuration manager and bindctl. That way we can agree there is consistency and intuitive. Versus have someone else design it, and then review only the code.
For example, boss changes needed to be discussed more before jumping into coding. I'll open a few tickets about this.

Jinmei: We had a design review phase for differences. Wiki page, discussion on mailing list. So in some cases we do that. I suspect in case of boss we thought that it might be a straightforward conversion.

Contest for Developers

Jeremy: Contest for developers... pay for top 3 open source user interfaces, that communicate via cmdctl. Publicity would be useful.
Michal: Makes sense, but I would wait until more people use it.
Shane: Not sure how well documented the cmdctl API is...
Jeremy: Documented but we need examples.

Steering Committee status

Shane: will send mail about this to team list.

Last modified 7 years ago Last modified on Nov 29, 2011, 8:30:09 PM