Changes between Version 1 and Version 2 of WeeklyMinutes20100615

Jun 15, 2010, 3:49:19 PM (7 years ago)



  • WeeklyMinutes20100615

    v1 v2  
    1 = WARNING: meeting has not ended, these minutes may be nonsensical =
    31== Attendees ==
    7 Michael
    12 Likun
    13 Jerry
    14 Jeremy
    15 Kambe
    18 Stephen
    2622== Action Point Issues ==
    28 Nothing to discuss.
     24Shane: I asked the Python community what to do about the Python 3 vs Python 2 decision. Will post a summary when discussion dies down.
    3026== !TracTimeEstimation ==
    3228Shane: I found a Trac plug-in which may help us gather statistics about time spent on tickets, as well as let us record estimates. Thoughts?
     30Jeremy: Is this where record manually how much time we spent?
     32Jinmei & Shane: I think so.
     34Jeremy: That's okay with me. I've done that with other ticket systems and I just estimate as good as I can.
     36Shane: Have a look at link I sent and we'll have a final decision next week.
    3438== 2010-07-01 release ==
    4044Code freeze date?
     46Jeremy: Code freeze on the 30th in the morning, so 24 hours.
    4450"New work stoppage" date?
     52Jeremy: Actually for finishing coding, I was hoping we could finish on the night of the 26th.
     54Shane: I was thinking a week...
     56Jeremy: Today is the 15th, which means we have only a week to finish up before the reviews.
     58Jinmei: Since this is a 1-month cycle, using a week for something not actually development doesn't make much sense to me. If this is a 6-month release maybe we need more period to mature the things. But my general understanding is that this is a snapshot release, so I think the freeze period could be much shorter, at the cost of having bugs in the releases.
     60Jelte: I tend to agree. If we are in the review period, it does not mean we cannot do other work, just not submit it for review for the release. But since this is a short time I also think we should keep it a bit shorter.
     62Jinmei: The more important thing is to perform code review more regularly, rather than at the end of the development period.
     64Michael: That means you have to assign the code reviews at the very beginning just like you have to assign the work.
     66Shane: At the end of your work day on 2010-06-24, no more code submitted for review.
    4870Requests for help, questions, and so on
     72Shane: My assumption is that if you are listed as a reviewer that you have time and are reviewing. If this is not true let me know and we will come up with a solution.
     74Jinmei: 2 important things for the next release are the non-Boost Python wrapper and the hot spot cache. Any other things would be relatively minor, so I will try to help these things be releasable, and do other minor small things.
     78Kambe: I have one request for statistics. Ticket #170 is ready for reviewing, so please assign someone as reviewer.
    5080== Architectural Discussion ==
     82Library rename: libdns -> libdns++
     84*Resolved, libdns is now libdns++*
    5288gprof, profiling in general
     90Shane: I think just the process time is not useful.
     92Jinmei: I think DTrace is one thing that is useful for this sort of thing.
     94Evan: I thought we did some profiling that showed we were spending a lot of time in sqlite3. I thought that was gprof... so if gprof is only reporting clock time so I don't know where that came from.
     96Jeremy: It doesn't have wall time.
     98Shane: Which version of Solaris are we running?
     100Jinmei: MacOS also supports DTrace.
     102Jeremy: We're running Solaris 10 on Sparc.
     104Shane: Does FreeBSD also support DTrace?
     106Jinmei: According to Google there is a presentation in a conference but it is not integrated into the mainline. DTrace is in FreeBSD 7.1, so maybe it is available.
    56110Python testing stat
     112Jeremy: I sent a list to the mailing list on some of that, and we have some projects that are missing Python testing.
     114Shane: We have a goal of 80% test coverage by the 6-month milestone, so this may be something we have to make an explicit goal by the next release.
     116Jeremy: There are 6 or 7 Python scripts that did not get any unit testing. Do I need to open tickets for that?
     118Shane: I think that's a good idea.
     120Jeremy: I won't create tickets for each script, but for each module/component.
    58122== A.O.B. ==
    60124Larissa talking to various ISP's at NANOG this week about their DNS needs - especially on the recursive side.
    62 --
     126Larissa: Talking to whoever is interested in talking. Talked to a couple of big ISPs, talking to a smaller ISP, talked to governments, talking to a couple of enterprise guys. A lot of people want modular, extensible, and high-performance. A lot of conversations about specific DNS tricks with IPv6 deployments. I will compile some data and sent it around when I get home. People are excited and I think I talked to a couple of potential sponsors.
    64 Shane going to be at ICANN 38 in Brussels next week from Monday to Thursday. Will try to have call as normal - if this is not possible, will arrange something else.
     130Shane going to be at ICANN 38 in Brussels next week from Monday to Thursday. Will try to have call as normal - if this is not possible, will arrange something else.
     134Jeremy: When we did profiling a few months ago we also did it valgrind, so I'll do it again. Also for wall clock, strace can give us for system call.
     136Michael: Not useful for us.
     138Evan: I have one suggestion, which I think I did for the year 1 release. I found that there was some advantage to reading the gprof data on only 1 library at a time. If you do it for the entire binary you get an enormous tree.
     140Michael: It's also important that we understand what gprof's limitations are. Recursion not working perfectly is kind of important. If you focus on the entire thing at once you're never going to get a good answer.
     142Jelte: I used kcachegrind to make graphs earlier.
     144Jinmei: I also saw a report from Jeremy about memory footprint. I've been wondering about whether we want to do any check about memory leaks.
     146Shane: That's a good point. I think the answer is "yes".
     148Jinmei: In BIND 9 we have an in-house checker using the system. Do we want to do a similar thing or do we want to rely on external tools.
     150Shane: I have used valgrind, and when it works it's great. I would rather do that.
     152Jinmei: External tools do not necessarily catch all memory leaks. Also, carefully written C++ is much better about memory leaks because we can encapsulate.
     154Michael: You can still have problems. But I think if we're going to do something special it should be as a library rather than instrument all of our code.
     156Shane: What's the best approach? I was thinking if we run valgrind with our unit tests then it should count them. Jeremy, can you see if we can run our unit tests with valgrind.
     158Jeremy: Noted!