Notes from the BIND 10 call




  • Roll call
  • AP from 2 weeks ago:
    • Shane to write ISC review process and put on TWiki
    • Michael to mail link with PDF for the DLV web site, which uses REST-ful interface. Wikipedia is probably best to start with.
    • Jeremy to add page to Wiki about stats.
    • Shane to try to make a graph of timeline
    • Jeremy to look into gcc test coverage
    • Shane to give commit access to Francis
    • Shane to check in BoB TODO
  • Review process
  • Face-to-face meeting in January
  • Data Source
  • AOB

Action Points

See above.

  1. Done
  2. Done
  3. Done (No design or protocol ideas: mostly open questions)
  4. Not done
  5. Done (Jeremy: Michael jump-started this. Reports are not being made automatically yet. Started looking at Python coverage. Jelte: Made Makefile target based on TestCodeCoverage steps.)
  6. Not done
  7. Done

Review Process

Jeremy: Jinmei did not know that someone was signed up to review his ticket. Some type of notification so he knew earlier.

Jelte: expected Trac to send notification...

Jeremy: will play with this, and double-check

Jeremy: do we want all ticket changes sent to bind-staff or some mailing list?

Jelte: would not mind, but danger that we start ignoring them

Shane: benefit is that unassigned ones don't get dropped

Jeremy: should be going to bind10-staff...

Shane: not working then

Shane: until volume gets too high, probably best to send to bind10-staff

Jeremy: then JPRS and CNNIC won't get them...

Shane: mostly to make sure we don't drop them, not for interested parties

Jelte: still not described on Wiki page who does the final merge back. If reviewer does it then it is credited to him, which may not be ideal.

Shane: good point.

Jelte: Subversion has a good merge command, so using a diff not necessary.

Shane: this is historical due to CVS evil... maybe either specify Subversion diff or leave unspecified

Jeremy: would be nice to have merge steps in the Wiki

AP Jelte to put up a link to description about that in the handbook

Jeremy: we have a page in Wiki about subversion

Jeremy: some guidelines on time, so things don't get stalled - so "reviewer assigned within 5 days" or "feedback within 5 days". Just something so communication needs to be in progress.

Shane: if we do have something like that, then we can make tools to remind people...

AP Shane to update Wiki with this stuff

Jeremy: does review actually mean running the code, tests, looking from a security aspect?

Jelte: it didn't even compile at first on my system, then ran tests, then read documentation, then read code... still didn't try to use the API

Shane: maybe we can write examples as a starting point?

AP: Jelte to write what he did as a checklist

Jelte: might be nice to have a tutorial for the API... but no time for that so far

Face-to-face meeting

25 to 29 January

Jeremy: how many in the year?

Shane: quarterly seems quite productive

Shane: concerns about excess travel are noted!

Data Source

Michael owes e-mail to dev list.


Jeremy: DNS message API in review process... what is it? What can we use it for? We have documentation for individual classes & functions, but I don't see the big picture. So I think we need simple applications - 10 lines of code to show examples for different things.

For example, I already have my "host" command, but API has changed so I would need to look through code and look through changes. Parking lot probably not ported to new API. Having a little application or a client tool go hand-in-hand with a tutorial.

Jelte: in ldns tutorials are generated from small applications, and I think this turned out pretty well.

Shane: does it make sense to do this just for the name API, or better to wait for the complete API?

...don't know... need to wait for Jinmei...

Jelte: need to make sure you document what is for internal use and what is not

Jeremy: New branch, with new RR API. Curious what the goal for the different things are.

Shane: I think this is based on the order that the work was done for prototype, and duplicating it for the production stuff.

Jeremy: For stats, maybe we need to start on end result and work our way back. Easy one is to start with BIND 10 XML stats fine-tuned. If we set this as the goal now we can figure out how to do it in the BIND 10 state of mind. Maybe each component can handle its own stats.

Shane: you think maybe we just need a class that each module can implement?

Jeremy: yes

Jeremy: Will be working on Python code coverage. Working on doxygen generation, making man pages from Jinmei's stuff. Automatically generated are not so nice, but give idea on holes to fill in and markup to extend.

"Do it if it's easy" was consensus (in regards to creating manual pages for APIs).

Last modified 9 years ago Last modified on Jan 4, 2010, 8:51:04 PM