BIND 10 Team Call




Year 4 Strategy

Lets discuss the year 4 plans as they are, including a discussion on:

  • Usability and other semi-related goals
  • Resolver work

Polishing. Get into a state where we can ask our friends to use it.
Probably: Usability for 6 months. Resolver for 6 months. (Original plan was to do DNSSEC add-on work too.)

Fix and clean up existing bindctl. Then create new user interface too.

Shared memory datasrc.

Release Schedule

Frequency? shane: may not need to continue with release every six weeks. If hardening sprint then that would be 1/3 of time and would be a high price to pay for bug fixes.
Fixed time interval.

First public official release? May discuss this at F2F.

Stephen: release when we have a new feature?

Jeremy: having frequent releases makes us look at it as a whole, and make sure it is reliable
Jelte: every release we find issues, so this is good to make releases often
Jeremy: and provides us with minor marketing\\ Mukund: "release early, release often"
Jinmei: it still makes sense to keep a fixed release cycle, given the maturity of the software; my only concern is if 6 weeks is sufficient given a hardening sprint
Stephen: so 8 weeks?
Shane: shall we try that for this release at least? [ Jeremy: 9 weeks because of week we lose in face to face?] yes

We will try four sprints for next release.

Run BIND 10 on AS112 server

Jeremy: New Ops engineer (Jeremiah) installed new FreeBSD server for AS112. In December we couldn't handle the traffic (60k queries/second). This week we'll run query performance tests on the box, and then help Jeremiah install BIND 10 and configure with AS112 zone. They will be able to switch back & forth between servers for testing.

To be done this week.

Intention is to blog about the experiences with AS112 experiences.

How can we move forward about the current "design" tasks?

Are we supposed to form a design team or something? Or is it okay for someone to send a tentative suggestions?

Jinmei: If we plan on discussing details at the face to face meeting it probably makes sense to have some initial ideas.
Jinmei: If we want to discuss shared memory at the face to face meeting it probably makes sense to have some ideas. I suggest we have informal suggestions for this task rather than make a formal design team.
Stephen: Maybe Shane can write up a summary of the discussion and post to list?
Shane: okay - agreed.

Jelte: I'll add a task to start a discussion about changes to configuration mechanism.

Longer term statistics plans

according to the recent status, I guess we won't be able to assume much separate development resource for statistics, so I think we should incorporate statistics related tasks into main (= non statistics so far) planning/development more intensively; otherwise we could end up having very few statistics related features in, e.g., 6 months. my tentative suggestion is to stop separating statistics task in planning, and simply allow everyone to work on any statistics tasks at any time at the equal priority with others. JPRS developers will still keep focusing on statistics related features best-effort basis; the difference is that others will also work on it.


Jelte: Also perhaps some changes to architecture of statistics...

How to review new members work

As more new members are joining, it's more likely to happen that a new developer reviews another new developer's work. It's not necessarily bad, but it will be more likely to cause missing some common review points (especially about the quality and coverage of tests). We should find a way to encourage contributions from new developers while keeping review quality. My tentative suggestion is that if both the developer and reviewer are new to the project, we'll have another mentor reviewer, who is a non new member and only for checking such basic points (this reviewer doesn't even have to understand details of the code). The tentative definition of new members is those who have attended 0 or 1 f2f meeting.

Shane: seems worth a try\\ Jelte: I thought perhaps we could just avoid both reviewer and coder are new, so this is a very good suggestion. We can't force it, so we should just check this.
Mukund: Wiki page on code review procedure; if followed should be fine. I think an experienced developer should actually check the code every time.
Jinmei: I suspect almost noone has ever read or remembered it (the review process thing).

Shane: I'll try to work on details of this process change - I think we should use our daily calls to coordinate.

Security procedure status update

(just checking: what happened about this?)

Jeremy: Larissa wrote up a procedure, but I haven't seen it yet. (Not BIND 10 related.)
Jinmei: Should be some BIND 10 specific topics (how we manage public Git repositories for example, or how we manage mostly open Trac tickets).

A trac ticket exists to track this.



New GIT server soon

(just a heads up)

Would be nice to have a gitweb or other web access to browse git history. (Maybe see if trac's will work again.)

Release Post Mortem (jreed)

goal of OpenBSD support was not completed and mixed logging fix not done

Build farm failures:
distclean target needed EXTRA_DIST additions
sqlite3 incompatibility disabled test

RT signers queue missing configuration that other RT queues had. (So I didn't think anyone had seen my request.) Now fixed.

FTP publishing script was broken.
FTP publishing steps changed again. (I had overlooked one change.)

Need Blog articles

Performance work. (Out of time to discuss -- will send note.)

Over at 16:00 UTC

Last modified 6 years ago Last modified on Apr 11, 2012, 2:07:00 PM