Sprint Retrospective

Stephen: How do people think that it went?

Stephen: I think it went okay. Anybody disagree?

[ nobody disagrees ]

Next Sprint

Stephen: How do people feel about where we are and the way forward?

  1. Logging API
  2. Interaction of remaining tasks

Stephen: I completed logging, committed, then we had problems with log4cxx. I guess that is my fault, I should have foreseen that different OS had different versions of the software. In the moment we are in the process of backing out log4cxx, so on release we will be able to log just to the console and nothing else. What do we do about logging? Options:

  1. We could write our own, or
  2. We could go for another package, or
  3. We could require that users of different OS have to get from sources if their vendor does not have a recent enough version

Shane: Do we use features only available in newer versions?

Stephen: Ubuntu & OS X use 0.10, problems with 0.9.7, and found an article showing changes in 0.9.8.

Shane: If it's backwards compatibility, we could use an earlier version...

Stephen: It's more fundamental. They changes from using multibyte characters to using a different class. (There were some Microsoft issues...) Created logstring class, which is a reasonably large change. As far as I can see the two versions are incompatible.

Stephen: I'd rather avoid re-inventing the wheel.

Shane: I agree.

Jeremy: I think installed a later version and we still had problems. I'll have to check...

Larissa: Last week on the team call and we decided that further reliance on external packages will cause us problems with being included in BSD...

Jeremy: This is the same thing.

Larissa: This is a concern of mine. Basically I agree that external packages makes sense.

Larissa: I think that even though our user base has shifted to Linux and our customers are Solaris I think this matters.

Shane: We're talking about BSD base, not being installed at all!

Jeremy: We've made it so the Berkeley DNS won't be included with the Berkeley's.

[ discussion of relative adoption of BSD and suchlike ]

Jeremy: Yesterday we committed some fixes to master so log4cxx will not be used. On some build systems log4cxx is bypassed. Builder results may or may not be using log4cxx. You can't tell by looking at the build report now.

Stephen: I think the way to go is to continue with the version that logs to console, and mark this as something we discuss at our face to face in March. I know we've discussed before, but log4cxx is just one thing that came up, and as we go down the line - especially as we get other fancy things - we may want to use other packages. So really get a definitive ruling on this.

Stephen: The other thing is the tasks remaining. Excluding the logging tasks, we have the following tasks:

#559 	lib/log test crashes with --enable-static-link stephen 	defect 	critical 	logging 	
#485 	Encapsulate sending fetch out which will be put into demux thing later 		enhancement 	major 	resolver 	
#488 	Handle referral 		enhancement 	major 	resolver 	
#490 	Handle packet errors from clients 		enhancement 	major 	resolver 	
#491 	Connect DNS cache 	zhanglikun 	enhancement 	major 	resolver 	
#493 	Negative cache 		enhancement 	major 	resolver 	
#554 	Abstract UDPQuery to IOFetch which will be transport layer agnostic 	smann 	enhancement 	major 	resolver 	
#500 	Query tracing (design) 		enhancement 	minor 	resolver 	
#501 	NSAS Glue Corrections 		enhancement 	minor 	resolver 	
#518 	resolver does not correctly use .spec's defaults 		defect 	minor 	resolver 	

Likun is not here, but we have a number of tasks in review for cache. Negative cache we spoke of a quick & dirty hack - which depends on the cache. Also, the NSAS glue corrections depend on the cache as well? Are we getting to the point where the cache is the bottleneck?

Jelte: Yes, I talked with Shane about this today, but looking now it is worse than I thought.

Stephen: Referrals and packet errors in clients can be done, 3 or 4 tasks that people can take, but everything else depends on the cache.

Jelte: Who reviewed the current state of the cache?

Scott: I reviewed the API design. Or the code?

Jelte: Ticket #449.

Stephen: Might have been me. Was there a problem?

    February 2011   
Mo Tu We Th Fr Sa Su
    1  2  3  4  5  6
 7  8  9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27

Shane: CNNIC developers will be back the 14th. Should we have the reviewer make changes (like in #449), or have someone else do the changes?

Jelte: 2nd way sounds better.

Stephen: I agree.

Shane: So tickets in review can be claimed.

Stephen: Also #491. Not sure whether he's started yet.

Shane: That will come after review, can be taken.

Stephen: Make tickets owned by likun UnAssigned? or just leave them?

Looks like #449, and #492 is the same task. If someone can take those we can go ahead.

Stephen: All assigned & remaining review tasks should not take much longer. We have 43 estimate points and we got through 19 in the last sprint. So we're in shouting distance of getting the whole lot complete in the next 2 sprints. However, are there tasks that we are missing?

Shane: I think we've been pretty good at making sure tasks got created when work is identified, right?

Stephen: This is the end of the 2nd sprint, so we're still going to need 2 more sprints to complete it.

Stephen: How about the testing? Actually doing the functional testing? Firing queries at specific configurations.

Jelte: Something we really do need.

Jeremy: CNNIC already has a resolver specification test suite they are using.

Shane: Something we can schedule for a specific time?

Stephen: Where are we as far as getting it working as an actual resolver? Can we build it and have it resolve and follow a chain of referrals?

Jelte: Oh yeah! And CNAMEs too. It's incredibly slow because we don't use the cache yet. Once it does that everything is just clean-up.

Stephen: So technically we do have a working resolver.

Jeremy: What about configuring?

Jelte: That's still a problem. We have't found a way to close one of the ASIO sockets. So if you stop a server it's sockets stay alive.

Jeremy: One workaround it to be able to tell BIND 10 to start the recursive server, but those options got ripped out. I'd suggest putting them back.

Stephen: We may also need to add a task to get the logging to get pulled from the configuration database.

Shane: Add them as tasks now?

Stephen: I'll put them on the backlog. Right now there's no way to set logging to debug.

Shane: It's a bit of a hack, but adding command line options is better than nothing.

Jeremy: You can say it's a hack, but we already have it for BIND 10 auth. So it's inconsistent how it is now.

Jeremy: I think there is a ticket already created for part of that.

Stephen: Apart from those we haven't come up with any new tasks that must be done.

Stephen: Are you satisfied with the features we're aiming for?

Larissa: I think the features are the best possible ... of the current situation. I don't feel like we need to shift our focus, as far as what we're getting for the end of year 2.

Jeremy: I still think we need to have a master checklist of all specifications we require and like to have. Right now it's a little bit ad-hoc. We research after the fact. It seems like we're going backwards for some things. Creating a big checklist seems like a huge job, but maybe it will give us something to follow. We're seeing discussions after the fact.

Shane expresses concern that this won't help.

Larissa: I think it would be an error to invest this time right now. I'm not opposed to this idea for year 3.

Stephen: I do sympathize with Jeremy. It is something I've raised before. BIND 9 has a lot of things fixed over the years. We're writing from scratch. I'm worried we release BIND 10, and then we get reports about things fixed in BIND 9.

Larissa: I think we need to deal with that specific issue in Year 3 by sharing time with BIND 9 developers. I mean Mark Andrews, because he has the most experience. I think it's a real issue but it is something that this is probably not the time to do it.

Stephen: We really do need checklist.

Jelte: And tests for those!

Stephen: That is true, although the first thing is to get the requirements because then you know what you have to test.

Jelte: It's not just specifications. There are a lot of weird scenarios that will fail with config setups and stuff like that.

Stephen: I think that in practice this is not a document you can write in one 80-hour sitting. I would suggest we divide the software into well-defined chunks and retrospectively create the documents, check against RFCs, look against bug lists.

Larissa: I think that is a reasonable task for Year 3. Also a good time to engage Maaahrk.

Shane: We'll need estimates for those tasks, do we want to do it via e-mail?

Stephen: We can do it after the Atlantic call on Thursday.

[ no disagreements ]

Last modified 7 years ago Last modified on Feb 8, 2011, 3:42:31 PM