wiki:WeeklyMinutes20130115

Minutes taken from Etherpad here: https://etherpad.isc.org/p/bind10-team-2013-01-15

Attendees
  • Shane
  • Jeremy
  • Kambe
  • Aharen
  • Mukund
  • Jelte
  • Fujiwara
  • Jeff
  • Michal

Release Discussion (10 minutes)
Hope to make RC1 after next sprint.
Shooting for 2013-02-07
Consider coordinating for Kea deliverable too.

Sprint Progress (10 minutes)
http://bind10.isc.org/query?group=status&milestone=Sprint-20130122

Jinmei: Due to #2435 several things are delayed. Not critical, but...

Jinmei: review queue longer than usual
Muks: two added today are new...

#2571? ready to merge
#2440? probably make it unassigned (not for next release anyway, but...)

Muks: 2 or 3 other bugs depending on #2435, and once it is approved will merge in; have been working on every day!

#2198? Go through dependent tickets and find out what to do next with this. Use new API from log4cplus before contacting log4cplus developers.

Great MySQL vs. PostgreSQL showdown (20 minutes)
We need to pick a winner, for which we implement first.
We also need to decide on the scope, as raised by Jinmei.
  • Fix the name encoding?
  • Store BLOB RDATA?
  • Other performance tweaks?
  • Generic SQL class with per-implementation specifics or...?
  • Captive vs. free?

Jinmei: Not sure if generic SQL layer helps. Code is small.
Jelte: already have part of this in our database client setup
Shane: okay makes sense to proceed as separate and we can refactor later if we need to

Shane: we have captive now, right?
Jinmei: not necessarily... you can update the database directly now, although XFR may not work as expected
Jelte: that is a actually captive database, since we don't guarantee it will work

Michal: Captive vs. free is important for why users want SQL
Jinmei: also related to requirements that we want from users

Jinmei: short term fix as many SQL-related issues as much as possible; no time to add another database before the release
Shane: not useable by early-adoptors among sponsors?
Jinmei: not necessarily, many issues can be fixed, and if serving from in-memory with SQL back-end this will not be a big issue
Shane: okay, I'm happy not implementing another SQL data source before the release then

Shane: so... look at defining captive vs. free next?
Jinmei: also requirements
Mukund: will we be able to support both?
Shane: yes, for performance you certainly want captive
Shane: although maybe with stored procedures & triggers we can have free that has everything we need

AP -> Shane to send mail to bind10-dev with the results of this discussion

Jeremy: need a system-level test to reproduce locking problems... ticket for that?
Michal: described in ticket, not sure how to do in lettuce test since zone was quite big
Shane: have to make a script to generate the zone?
Michal: do we want a lettuce test that runs 5 minutes and takes several hundred MB of disk space and memory
Jelte: ideally you have a fake upstream server that stops sending data...
Michal: I did it with loadzone, but also maybe with xfr-in.
Jelte: another reason to support loading from streams instead of files
Shane: make it an optional lettuce test possibly?
Jelte: on my system lettuce tests takes 3.5 minutes

ChangeLog entry clarification (10 minutes)
Jeremy reports: "We have been inconsistent with the changelog entries for developers. Some aren't recorded, some are summarized, and some specifically name the functions (etc)."
Probably we need some clarification about the target users for the ChangeLog, and what we expect for each of them.

Jeremy: some changelog entries were highly technical, written for developers; some not technical written for administrators; changelog entries are also used for release notes and announcements
Jeremy: be more consistent in how they are used

http://bind10.isc.org/wiki/ChangeLogDetails

Jinmei: what inconsitency? some technical and some operational?
Jeremy: yes, and some by themselves don't help anybody since there is no context; for example one was about options but did not mention DHCP
Jinmei: I don't think that is consistency, just a bad - non-helpful - changelog

Jelte: I did change something module writers might use; the only category was "functionality", which did not really feel right
Shane: do we need an API category?

Jinmei: if the concern is some changelog entries are not helpful, we should improve that and I understand that
Jinmei: we have been trying to do that by checking the usefulness of the changelog in the review process; sometimes Jeremy asks questions about the intent of the changelog; we basically try to spend some effort on that. Of course it cannot be perfect. I don't think it is so bad, if we can improve that is nice.

Jeremy: it is about when APIs change. Some APIs tell you the name of the class/function others just specify it, others do not. The developer may not know where to look.
Shane: well that's the diff itself right?
Jelte: yeah but if you have written against our API it might be helpful to know.

Mukund: our changelogs are not really changelogs... it is what we would put into NEWS files for GNU software. changelogs are commit messages.
Jinmei: we intentionally wanted to provide more detail than 1 or 2-line changelog

Mukund: this should be a document, not just fragments, for example if you want all the API changes, an editor should check this and get someone to fix it
Jeremy: I agree with that, but there is too much time involved. Sometimes I may spend 4 hours just trying to figure out what the changelogs are; if we wanted to do it good someone would spend 8 hours on it or even 2 days.

Jeremy: About NEWS vs. ChangeLog... I agree. At x.org we had a script which generated the ChangeLog directly from git commit messages. So generate ChangeLog from git and put summaries into NEWS?
Jeremy: Summaries are definitely needed though.

AP -> Jeremy to send mail to bind10-dev documenting issues

Buildbot updates (10 minutes)
  • Shall we get an Ubuntu buildbot? It seems to show some issues unique to that platform.
    • Ubuntu very popular; no reason it should not be supported
    • Could potentially leverage Jenkins effort (Jeff) to add an Ubuntu build agent (currently all servers BSD) - let me know if you want me to do this
  • Also some reports to me about Solaris SPARC GCC issues; may need a new system for this.
  • On the builder status webpage, shall we have all the non-master builds in a different section?

MSGQ improvements
We mentioned it on the last planning call. Should we do something about it now? Possibly:
  • Proper configuration and commands (like shutdown, requesting list of connected clients).
  • Handling of errors and undeliverable messages in msgq, not by timeouts.
  • Allowing asynchronous receives in the client library.
  • Making notifications work.
  • Sending notifications about connected, disconnected and subscribed clients.

Michal will pick some of his old tickets and move to proposed.

Jinmei: writing more tests is probably among the more important
Jelte: in the statistics (?) unit test has a mock msgq, and everything changed in the msgq breaks these tests

Jeremy: we talked about the msgq being a generic software for this type of work... is this still a goal? Or is it purely BIND 10?
Michal: I don't know but I think we should start by making it usable by BIND 10
Shane: msgq did not have dependencies, it does now... 
Michal: logging and libraries that connect to msgq
Jelte: will also be depedent on configuration libraries, that should be optional
Michal: will work without cfgmgr, but will need some other way to get its config

Old Agenda Items

Return NOTIMP if zonemgr is not running? (Is this #2562?) and discuss cannot control the rate of incoming notifies

Inconsistency in style around pointer?bool conversion
'if (pointer)' is allowed for smart pointers, but not for bare pointers. Why & should we do something about it?

BIND9:
  good
if (ptr == NULL) do_some
 bad
 if (ptr) do_soem

Consistency with BIND 9 is not a requirement.
Related to difference between C++ and C, so makes sense to be different.

Result: remove requirement to use explicit comparison for bare pointers

Prioritizing most important fixes for the final 1.0.0 release to consider for final sprint.
How should we use the "priority" field in trac tickets? And "Next-Sprint-Proposed" milestones get dropped so if not manually re-added then an important ticket may be ignored.
  • python 3.3 is default from python.org. (multiple tickets) #2621, #2622, #2623, and then #2501
  • Upgrade docs (how to restart)
  • document what is not "production quality", document known issues (for example SQLite locking issues)
  • #1622 Try log4cplus 1.1.0's "UseLockFile"
  • #2367 select features to build and install, kea vs. dns for example 
  • #1901 match names, be consistent with naming (Boss vs. bind10 vs. BoB, StatsHttpd vs. b10-stats-httpd, Auth or b10-auth, etc.), allow lowercase.
  • #2261 data_sources configuration is at top-level -- is that confusing to Kea-only admins?
  • #2262 tsig_keys configuration at top-level -- is that confusing to Kea-only admins?

Michal: proposal of "dropped tickets" milestone
Jinmei: also nice to have a counter of how many times proposed (can add that)
Shane: are also voting extensions

AP -> Jelte to create "dropped tickets" milestone after next sprint planning
AP -> Shane to research ticket lifecycle on Trac site and add page if not there

Jelte to look and see about feasability of counter of how many times proposed

Mukund: need to look at backlog on a regular basis

----

Michal: we could have a table of green/yellow/red for each module
Shane: on wiki or BIND 10 guide?
Michal: I think wiki is slightly better

AP -> Michal to try first attempt at this

----

AP -> Shane to raise #2367 with Stephen again
(I talked to Stephen about it; not in our sprints, not in their sprints ;)

----

Michal: Plug-ins need some design work to decide how they look like
Jeremy: would it make sense to make a quick hack to put data_sources and tsig_keys under dns?
Michal: You would have to unify into one, which would be slightly messy; could be done, not sure if we want to do it....

Where to define exception class thrown from a specific class.
  Specifically, within that class or outside of it:
  style A:
    class ExceptionFromSome : public Exception {}; // thrown from Some class
    class Some {
    };
 style B:
   class Some {
       class ExceptionFromSome : public Exception {};
  };
 We have mixed styles.  It's better to unify the style policy, and I now propose adopting style A.
 See http://bind10.isc.org/ticket/2435#comment:16 (about rrset_collection_base.h)

Will discuss on list!

Should we make dns::rdata::generic::detail::CharString public?

It is for handling <character-string> parts in DNS messages, but the hidden implementation requires forward declarations and/or pimpl and dynamic allocations in rdata code. I think we should consider making it public so we can use CharString members in header files. And perhaps we should also make it a real class instead of a typedef with static helper functions.

Jinmei: okay
Jelte: it's a typedef, maybe we should make a class with methods. will make ticket
Michal: typedef + bunch of functions lying around, so not looking nice
Jinmei: make it a class or not may be subject to discussion...
Jelte: will take to list then!

Call done at 16:01 UTC

Last modified 5 years ago Last modified on Mar 12, 2013, 11:18:24 AM