Minutes from the Etherpad here:

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

Sprint Progress (10 minutes)
Holy crap are we out of tickets?

Look at minutes from last planning session to try to find additional work, as needed.
Or next-sprint-proposed.
Or Jeremy can suggest something. :)

#2440? (#2441 depends on #2440) Shane will talk to Meadhbh

Delay of Release Candidate
  • Orig release date target was 2012-02-07
  • Delayed due to Kea testing by 1 week: 2012-02-14 for RC1
  • Probably approx 1 week later, general release for 1.0.0 (2012-02-21)

Daily Call Time (10 minutes)
Shall we move the daily "stand-up" call back to the 08:00 UTC time?
We can "unlink" it from UTC to move it earlier in summer if that makes sense.

No (vocal) opposition.

Face to Face Meeting (10 minutes)
We have approval for a Face to Face meeting!
Current  target is 2013-04-15 to 2013-04-19, and this will include the BIND 9  developers, and be conjoined with a Kea / ISC DHCP team meeting.

The Social Medias (5 minutes)
ISC has a couple of people that will be working on PR for the BIND 10 release.

Continuous lettuce test failure (? minutes)
  this seems to be a setup issue, rather than a real bug, but the frequency of the failure now looks rather harmful.
  we should consider something else, or even stop it if we readlly don't have a good alternative.
Shane proposes increasing timeout.

Protocol errors log level
Some protocol errors are logged as INFO, even if they _ERROR in their message ID. Is that OK? If so, what is the rationale behind that?

Jeremy mentions that there are lot of messages like this, that say _ERROR as part of their ID but are not errors.

(in xfrin)
        except XfrinProtocolError as e:
            # FIXME: Why is this .info? Even the messageID contains "ERROR".
  , req_str,
                        format_addrinfo(self._master_addrinfo), str(e))

Jinmei: Partially about general policy of this kind of event. Also there is one particular instance which triggers this discussion (pasted above).

Jinmei: Normally events triggered outside of box are logged at INFO or lower.


Something has happened such that the program can continue but the
results for the current (or future) operations cannot be guaranteed to
be correct, or the results will be correct but the service is impaired.
For example, the program started but attempts to open one or more network
interfaces failed.

An unusual event  happened.  Although the program will continue working
normally, the event was sufficiently out of the ordinary to warrant
drawing attention to it.  For example, at program start-up a zone was
loaded that contained no resource records,

A normal but significant event has occurred that should be recorded,
e.g. the program has started or is just about to terminate, a new zone
has been created, etc.

In this case we can change _ERROR to _ISSUE or something. _SNAFU. Whatever. :)

Jinmei: in BIND 9 these events are generally logged at error level. For example, if remote server did not send SOA record as expected, gets logged as error. In general BIND 9 has a simliar categorization with INFO/ERROR levels. Not sure if intentional, or accidental. Perhaps because XFRIN is special, in that the remote systems are limited, and you can fix if it happens.

Jinmei: So error may make sense in this particular case. If that is true, we should change from INFO to ERROR (or something).

Conclusion: rename symbol.

TODO: create task to do an audit of logging symbols to look for _ERROR mismatches (will add ticket)

Documenting differences from Bind9
We have several differences from bind9. How much detailed do we want to be in documenting them and where should they be documented?

Example I just saw today:

No place today.
Should have a place collecting BIND 9 differences.

Jeremy: Wiki for now?
Michal: IT will stay there... also differences may vary from version to version.
Jeremy: I just meant a holding place for ideas...
Michal: Just a file in doc/ directory? Same work.

We need a ticket to document the full differences

Jinmei: guideline is to be reasonably detailed, for relatively minor differences; beyond that we can use disgression
Jinmei: also behavior difference with other implementation


1. Create file that documents differences
2. Create guidelines for includeing differences going forward
3. Review and document existing known differences

Jeremy: sounds like a blog article too

After release?
Focus will be primarily on housework (cleanup), and the resolver

Over at 15:39 UTC

Last modified 5 years ago Last modified on Mar 12, 2013, 11:16:31 AM