Minutes taken from Etherpad here:

  • Shane
  • Jelte
  • Michal
  • Aharen
  • Jinmei
  • Jeremy
  • Fujiwara
  • Kambe
  • Paul
  • Mukund

NEW TEAM MEMBER (5 minutes)
Welcome to Paul Selkirk

Need new plan for daily "stand-up" call.

Release Post-Mortem (15 minutes)
Jeremy: Easy since we started with RC. Changes to documentation (DHCP IS EXPERIMENTAL!), and version upgrade.
Jeremy: Fix was done, conflicts on merge, no tests for fix!
Jeremy: Marketing & web site still not complete. BIND 9 lets you fill in information, BIND 10 forces this.

1.0.0 released.

Keep time between rc and release relatively short;
2 weeks as maximum.

Mostly easy since only a few minor changes for doc update, version 

There was various discussion about a dhcp bug  
(fix was done, but no tests, merge to master lost it, maybe due to a conflict).
Website parts confusing, not complete. 
Download link from it was wrong, and is bad to require email to get it.
Very little discussion and feedback.

-Werror discussion. We ignored things for last minute.

Sprint Progress (10 minutes)

Breaking Up the Band (10 minutes)
Shane & Stephen agreed to split up BIND 10 into separate releases:
  • BIND 10 Core
  • BIND 10 DNS
  • BIND 10 DHCP
The current BIND 10 DNS team will be largely responsible for "core" at least for now. (Some day a separate team might arrive, but...)

Single source tree? Different tarballs? Same tarball with different configure switches? points to one of discussions on mailing list.

By the way, the debian packager created:
and wants too split out dhcp libraries too.

Can we do this for the 1.0.1 release (5 more weeks)? Should we?

Need request-for-pullup for changes to master that might go into release branch.

Jeremy: Too early for bugfixes only? Just roll a new release!
Mukund: Maybe we should just release from master. We haven't talked about stability.


-Werror in release (5 minutes)
This is already being discussed on the lists, but we need to make a decision.

Shane to reply on list, stating that we will disable in git + release (as per Jeremy's patch).

API/ABI stability (15 minutes)
There are some tools that can be used to verify ABI stability. But even before
that, are we ready for stabilty? If we want people to use libdns++, we need to
provide a guarantee of ABI stability. Distros will likely not agree to break up
libdns++ into a separate package (with a -dev package for it) if they know
that we don't have a plan to stabilize the interface.

This involves discussing if we're ready to do so, what major, minor, micro
versions mean to us in this case, working with libtool, adding checks to our
unittests such that nothing in the whitelist API is changed unless the arg passed to
libtool -version-info is appropriately modified.

We can keep bumping up version numbers and update ABI, but how long do we intend
to support a particular ABI? Distros may want some assurance from us that a
library that is shipped will be supported for bug and security fixes during
the lifetime of that distro version.

The debian package specification has lists of the symbols:
$ wc -l *.symbols 
    82 libb10-cryptolink0.symbols
  2931 libb10-dns++2.symbols
     8 libb10-exceptions0.symbols
   127 libb10-util0.symbols
So they can track this.

AP: create a README/guide about API's saying that they are not (yet) stable

Jeremy: do we have guidelines for when libraries are stable?
Answer: API review

Mukund: you can change libtool to only export whitelisted symbols

Move severity to .mes files? (15 minutes)
Shall we move the severity to the .mes files itself, so that the logging call
does not have the severity specified? We had the recent discrepancy between
message ids containing '_ERROR' suffix, and the severity being non-ERROR.

Michal: Was a problem... performance.
Jelte: Every message could be a macro.

Shane: Also can't tell how severe a message is when reading the code.

Do debug level numbers at same time?

B10_FROM_SOURCE vulnerabilities (10 minutes)
(This is perhaps something to discuss on our call than the lists.)

We have to be careful when using B10_FROM_SOURCE and similar environment variables,
as there seems to be a way to override many files. Though BIND 10 will be started
in a controlled environment, it's good to keep these env variables in mind when
writing code to do with authorization, etc.

We have a ticket about clarifying and cleaning up environmental variables. Perhaps we should do that. :)

Michal had an idea to set a switch at ./configure time to specify when you are running from source.

Update .gitignore files whenever you delete something or add something (10 minutes)
Ticket to try to find automated way to do this.!Sprint-20130305
These are bugs that are in "reviewing" state, but are not being worked on.
Some of them probably have patches (as they wouldn't be in reviewing state
otherwise). We should see about these and fix/merge or put them to some other state.

Shane will have a look and clear those out.

Config-ng plans
Time for the major overhaul?
Michal: Maybe work like msgq overhaul? (Which we should finish first.) Jelte had concrete ideas about this...
Jelte: I did... at some point in the past. We have additional requirements now.

Shane: Will cost of building missing features be cheaper with a fixed configuration system?
Michal: It might, but I think not significant.

We need to consider c++ library configuration parser too. I received some feedback last week about python as a show stopper for some.

Perform some higher-level design task to figure out how big it is... might not actually be a huge amount of work (relatively speaking).

Over at 14:00:00 UTC

Last modified 5 years ago Last modified on Mar 12, 2013, 11:23:21 AM