Stephen: What did we get in our 6-week cycle?

Async I/O, NSAS

Stephen: Is there new functionality in this release?

Jeremy: For the past 6 weeks, new functionality or since very last release?

Shane: We have a new application in the release?

Stephen: Change 327, all sub-tickets done, so waiting for final review before merged back into trunk.

Michal: A lot of work was on NSAS branch. Sub-branches to that.

Jeremy: new features - new configuration for zone manager, stats module is in trunk (needs to be documented more)

Shane: Sprint does not require user-visible stuff...

Stephen: This links into review of Scrum. Had branches of branches. Do we want to continue this?

Shane: We did branches of branches because they were large & hard to review?

Stephen: #327 was because Evan was taken off...

Jelte: As I recall, we did not want whole team to wait until finished, wanted parallel work. Should try to avoid as much as possible, although maybe not always...

Michal: Bigger problem is branches live too long. Branch & merge 2 days does not matter if we have sub-branches. But if a branch lives 2 months then it has too many collisions and is almost impossible to merge back because reading the whole diff is quite large.

Stephen: If there are so many conflicts, is that a suggestion of a poor modularization?

Michal: Well there were these changes as well and when we come to the fact that Subversion is able to find a collision where git would do a fast-forward merge. It adds a lot of work (for example a file removed in both branches is a "collision").

Stephen: I am sensing the concensus is that we should avoid branching from branching. What do JPRS and CNNIC think about that? Any comments on this issue?

Aharen: Are we talking on ticket #327?

Stephen: That is the example. What we have done is take a branch (#327) and before merging to trunk we have made branches from that. So we have done a lot of work not committed to the trunk.

Aharen: I made a change on asio to add interval timer, which might be conflicted on trunk.

Stephen: We've almost got 2 trunks and it will be harder & harder to merge them.

Stephen: We've got to make tasks smaller to merge them as quickly as possible.

Stephen: What has gone right and what has gone wrong (with Scrum)? Any comments please.

Jeremy: I was concerned that maybe we are working on building blocks of new features versus minor bug fixes of existing features. If we continue on that path we will have lots of broken features versus working features.

Stephen: Are all bugs and broken features on Trac?

Shane: Yes.

Stephen: I don't think we can exclusively go for just correcting bug fixes. But we have to make sure we keep up to date with fixes.

Shane: Bug fixes are just user stories. Larissa and I have been acting as proxies for users, but not as *real* users.

Stephen: Maybe Jeremy can highlight what the most important bugs are for a sprint?

Stephen: How many bugs do we get reported a week?

Jeremy: Reporting is just us... maybe 10-15 a month? Most are very minor probably.

Stephen: If we get 10-15 a month, if we aim to complete 20 bug fixes in each month, 10 per 2-week sprint, each team should tackle 5 per month. Ultimately number of bugs should start going down.

Michal: Did the number include tickets opened for tasks that need review?

Stephen: No, these are actually reported bugs.

Jeremy: Trac does not really diferentiate them.

Shane: 129 bugs, looks like roughly half are defects.

Stephen: If we can get top 10 we'll add 5 to task list for A-Team and 5 to task list for R-Team.

Michal: Try to split by who is closest to code?

Shane: Mostly to A-Team now because that is where code is now, so probably not possible.

Stephen: Maybe we can do low-hanging fruit first. :)

Stephen: Seem to be chasing on building blocks rather than features. The idea with Scrum and with task selection is that we have the user stories and that the entire team breaks that into tasks, then the team breaks that into tasks for the sprint. We do the estimation and then do the tasks and we can plot how much we are doing, and we get team velocity. That allows us to do some planning. Stephen: That does require a lot of work from the team in doing analysis. We had a try at doing that and it was not particularly successful. The 2nd sprint happened when most of the team was at the IETF. We did the same for the 3rd since everyone was away.

Stephen: This time I did a set of user stories and tasks and presented them for discussion. If there are no comments or objections, shall we start on doing the task list.

WebEx Task list

Ticket #327 combine shared code.

Michael: Wait until #327 is merged into trunk.

Ticket #412 looks complete.

Jeremy: Trac #412 added recursive server?

Stephen: Just a placeholder code, until #327 gets merged. Will change ChangeLog.

Merge #327 into trunk... estimate 1 day?

Michal: For merging only, can maybe be done.

Stephen: The review of all tasks we'll say 2 days.

Design Phase 1 & 2 is just getting Evan's thoughts on #327.

#408 is still ongoing.

Michal: Kind of changed the interface a little bit a few times and then had to change the code, so it took longer than expected because of that. I'm not sure where to do the split so maybe I am adding parts which are not for this task. And there is a discussion of using the recursor for that as well.

Logic to update the RTT.

Stephen: Ocean sent mail and needs review.

Ticket #403 - "fixing the / bug"

Jelte: complete

Basic support for addressing individual list items

Jelte: Task done, but review is open.

Fixing bindctl printing of config data.

Jelte: Some work, but depended on previous one so partially done.

Select New R-Team 2-week tasks


Next 6-weeks will end in face-to-face meeting.

Stephen: What should it be?

Jeremy: Simple forwarder.

Shane: I think we need to start towards the cache.

Stephen: How do we know when we have gotten done?

Jeremy: Some commercial DNS authoritative server suites.

Stephen: What I'm worried about is that there are lots of tweaks and changes over the years, and if these features are not written down we will not implement them and then people will start complaining that we don't act like BIND 9.

Jeremy: 6 months ago Michael graph had a presentation of some code written in Ruby but it never went forward. So I didn't know... if that's the case use it, if not we need to start doing something now.

Stephen: I think this is a management thing. This is documentation "these are the features in BIND 9".

Jeremy: I think this a deliverable in 2 parts: a checklist and then a test case for each of them.

Stephen: The next one is the logging framework. One of the tasks in the last sprint was Michal going through the recursive code and noting where log messages were output. I noticed a lot of stuff going to stdout. Maybe we should make a start on the logging framework and make calls to the API. If we do it right the first time we'll save ourselves some work.

Jelte: Yes.

Stephen: Offline configuration / standard initial profiles. If you want to change BIND 10 now you have to start BIND 10 now.

Stephen: DNSKEY interface. We need to figure out how to organize DNSSEC keys - both for auth and recursive servers. OpenDNSSEC agreed to use HSM PKCS#11 only (with SoftHSM). We'll probably need to support existing key files, although we could write an HSM-type interface to access the key files. Anyway it will be common and will need to be done at some point.

Shane: We do need trust anchors.

Jelte: And a crypto API.

Stephen: Priming query and the priming query logic.

Stephen: Cache. Cache cleaning. Caching negative responses. Cache persistence. Pre-loading cache. Glue caching. Pre-configure authoritative data to cache? Testing by pre-loading cache.

Stephen: NSAS. Did not have persistent cache, but question whether should be.

Stephen: Actual lookup logic in non-DNSSEC case. Extension of logic to DNSSEC case. DNSSEC validation, which will be built on the crypto library.

Stephen: Programmer documentation - especially of the ASIO link & ASIO stuff.

Jeremy: New ASIO changes in track #327 cause a 13% performance loss on the authoritative server. So maybe that needs to be profiled & explored.

Jelte: We know at least one cause and possible solution.

Stephen: Is that recursive or general?

Jelte: Both. I think because we do a lot of allocations on every query now.

Jeremy: We're planning on loading a master file into memory cache. We already have b10-loadzone (which is broken). I'm trying to understand why duplicate. We should either get rid of b10-loadzone or use it. Whatever the target is we only need 1 parser!

Jelte: I actually want a decent string parser in the DNS library.

Stephen: Do we think we have a week work now?

Michal: Starting design of cache will help prevent big tickets.

Stephen: We're trying to deliver a resolver by end of March, we need some sort of cache, would it be a good idea to write a quick & dirty cache and concentrate on recursor logic?

Michal: Yes but we need to know approximately what we want the cache to be able to do. So we could put a task like "identify what a cache should look like from outside". After working on the NSAS I think we already have a strange requirement (0 TTL caching).

Stephen: What do you think of the idea of getting the API for the cache out with the view to refactoring it later if necessary?

Shane: I think it's a good approach.

Stephen: If we do the requirements and API design on this sprint?

Shane: Maybe also tests for the API?

Stephen: We also have use simple recursor as a story. What other components should we do in this sprint?

Jelte: I want logging!

Stephen: We could do the API design. We discussed on the list. We get our own API based on our requirements, then use one of the readily available logging frameworks.

Stephen: I think think there are bodies to work on code. We have a lot of tasks that will be requirements, design, API. How about the overall processing for the recursor - at least the logic for that.

Stephen: Basic design of lookup logic in non-DNSSEC case.

Stephen: How about persistence for NSAS?

Shane: Does not exist in BIND 9 today, not so important...

Michal: Not too difficult. Only technical work, so not needed for now, can be done any time.

Stephen: Also 5+ bugs. And reviewing tasks. Is that enough for 2 weeks. Is that enough?

All: Enough!

Stephen: If not enough Jeremy can find us more bugs to fix.

Stephen: Ideally we should make estimates for these. Lets leave it for now until I update the Wiki page. Maybe we can have a slightly extended morning session when we try to estimate?

Michal: I will be in school tomorrow morning, but if you leave it until Thursday I will join.

Stephen: Also if people can send estimates I can do this. I'm trying to get as much as possible offline.

Stephen: Estimates will go privately to me, so they will occur in a complete absense of knowledge of what other people have said.


Jeremy: Every 6 weeks I will do a snapshot tar release - one thing is last-minute commits to trunk. If & how we want to include them. I can create a snapshot before they are committed...

Stephen: Maybe create a snapshot 2 or 3 days after the sprint is finished, then we can sort out last minute problems.

Jeremy: Sometimes Jelte has worked 10 hours straight fixing minor issues at the end of the release...

Stephen: We can allocate 2 or 3 tasks for "release fixing" for previous sprint. Make a release 1 week after previous sprint...

Jelte: Normally we have a "hardening" sprint, but our current use of Scrum is not yet settled enough to do that. So now we have to do like you suggest and make time for that.

Stephen: With "hardening" sprint there is an implicatation that there is enough work.

Jeremy: These are just experimental now - we don't want to ship regressions. But for now these are fine.

Shane: Maybe we can dedicate time in the "hardening" sprint to fixing bugs if we have time.

Jelte: If you click "accept" a ticket moves from "reviewing" to "assigned". Just FYI.

Last modified 7 years ago Last modified on Dec 3, 2010, 9:37:23 AM