wiki:WeeklyMinutes20100706

Attendees

Likun
Jerry
Shane
Fujiwara-san
Jelte
Stephen
Jeremy
Larissa
Shawn
Hankins
Jinmei
Evan
Michael

2010-07-01 release post-mortem

Outstanding issues

Jeremy: Nothing for release itself, but outstanding items on ticket list.

Shane: I'm closing or reassigning tickets from that milestone.

Problems with release

Shane: Kind of rushed at the end.

Jeremy: We did better because we had the first deadline. More of the focus was finishing up reviews, versus asking for reviews at the last minute.

Jeremy: A few different commits (Monday? Tuesday?) caused build errors on 4 or 5 different platforms. Something on Debian, something on MacOS, something on FreeBSD. All separate issues! These were all minor issues, but it added up.

Shane: The system worked, right?

Jeremy: Other than the !MacOS issue. None of our builders caught that. Maybe Jinmei has more details?

Jinmei: What is the !MacOS issue?

Jelte/Jeremy?: You needed "-module" in the Makefile somewhere.

Shane: The thing about !MacOS is that you need a Mac...

[ some discussion of the ISC test lab ]


Jeremy: Missed communication.

Evan: We decided we were not going to put the hotspot cache on the release. Then Shane, Jinmei, and myself had a meeting to try to get it reviewed and ready for release. Then I sent a message to Jeremy, and spent the day working on the code, got it all ready, then contacted Jeremy and an hour later he noticed these and he had already rolled the release.

Jeremy: I was in the BIND 10 jabber room all day. An e-mail also would have been fine.

Shane: Back to the !MacOS issue.

Jinmei: We have developers using OS X, so I think it's okay not to have that.

Jelte: PowerPC would actually be a good thing...

Shane: We have a Sparc, right?

AP Jeremy to talk to Rob about the !MacOS box in ISC testlab.


Jeremy: Milestones listed several tasks not specific for this release. Maybe having two milestones that are separate? Some were for researching or planning, for example with statistics.

Shane: We have non-release work, I have put these in releases.

Jeremy: We have building blocks, but we don't know the deadlines for the next part and the next part. Maybe if we had a big picture, with future deadlines.

Changes in future releases

Shane: Maybe we could use the the Time and Estimation plugin for Trac?

Jinmei: I think it could be useful, but there may be implementation-specific issues.

AP Jeremy to look at Time and Estimation plugin.

2010-08-12 release

[ Jinmei suggests skipping the August release due to meetings and vacations, but consensus is to stick to current dates. ]

Goal, assignments

Working Style

Shane: I sent mail. Read, and we will discuss next week.

Architectural Issues

Jelte: Synced branch for writable data source, and discovered hot spot cache. Is there a way to declare underlying data as dirty?

Evan: No, I decided not to do it until there was call for it. We can do that now. Currently defaults to 30 seconds now, so...

Evan: Do you want to clean individual names?

Jelte: For now, just flushing everything is good enough for me, but in the end more granularity might be good.

Evan: I'm inclined to think we would rather have granular clearing. Is it possible we don't know which names to clean?

Michael: Might I suggest this is a good chance for test-driven development?

Evan: Granular clearing is better unless not possible.

Jelte: It can be on record or zone level from my point of view.

Evan: I can do it with name/class/type quite easily.

Shane: How coupled are the hotspot cache and data source?

Evan: Top-level data source routine has been more complicated - it consults the hotspot cache. DoQueryTask() routine. Real goal was to minimize database access, not just to have a hotspot cache. Query every data source to find out if responsible for given name - now we can store that in memory.

Jelte: I can actually use that!

Evan: DataSourceMatch, since NameMatch went away.


Jinmei: Question about consistency between data source and caching. Should we also consider the case of non-captive database?

Shane: The PowerDNS answer is "don't worry about it".

Jelte: You can make the timeout configurable.

Jinmei: I don't have a solution, but I guess we need to think about these issues. If we need to provide a solution in one case I guess we should provide for the other, or vice versa.

Shane: We'll have to think more deeply about this. Perhaps a topic for the face-to-face meeting?

A.O.B.

Jeremy: Build using Sunstudio on Sparc builds but does not run. I'm trying to track down where & how it's failing. I was trying to find an overview document explaining how the auth process works, so I was thinking that might be useful. I can start working on this myself. Sort of like a flowchart of how a query comes in, which function might be processing it, and how it returns a response.

Jeremy: Or do we already have something like that?

Jinmei: I don't think so.

Jelte: It would be cool though.

Shane: Do our unit tests catch this?

Jeremy: Our unit tests don't run on the C++ side, which I am also fixing.

Jeremy: It might be useful to have the Python test suite duplicate the C++ test suite. Does it already do this?

Jelte: You mean have exactly the same tests?

Jeremy: At least... and maybe more.

Jelte: I started out doing just that when I began work on the wrappers, but after a while I thought it was wasted effort and I could focus on testing the wrappers themselves. For a few classes they are still there, but not nearly all of them.

Jeremy: Does it make sense to have everything tested?

Jinmei: I think it is generally good to have more tests for the Python wrappers, but I don't think duplicate test cases for C++ and Python make sense. Ideally we would have one source and auto-generate the C++ and Python test code. But this is probably very difficult if not impossible, so I don't know if we can do that.

Jelte: I don't think so.

Jelte: I think more important to get the Sunstudio working rather than duplicate them in something that already works.

[ Jinmei and Jeremy discuss getting the googletest to work with Sunstudio ]

Shane: This is our 3rd compiler? We have llcv?

Jeremy: llvm does not work yet.

Jinmei: I think we should consider supporting Windows in an early stage. I know it's not possible today, but Visual C++ is a very popular compiler. It would be good if we had support for that in an earlier stage. Maybe a topic for the next face to face meeting.

Last modified 7 years ago Last modified on Jul 6, 2010, 4:11:25 PM