Changes between Version 1 and Version 2 of WeeklyMinutes20100615


Ignore:
Timestamp:
Jun 15, 2010, 3:49:19 PM (7 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WeeklyMinutes20100615

    v1 v2  
    1 = WARNING: meeting has not ended, these minutes may be nonsensical =
    2 
    31== Attendees ==
    42
    53{{{
    6 
    7 Michael
    84Shane
     5Fujiwara
     6Kambe
    97Jinmei
     8Jeremy
     9Stephen
    1010Jelte
    1111Shawn
    12 Likun
    13 Jerry
    14 Jeremy
    15 Kambe
    1612Larissa
     13Michael
     14Hankins
    1715Evan
    18 Stephen
    19 
    2016}}}
    2117
     
    2622== Action Point Issues ==
    2723
    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.
    2925
    3026== !TracTimeEstimation ==
    3127
    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?
     29
     30Jeremy: Is this where record manually how much time we spent?
     31
     32Jinmei & Shane: I think so.
     33
     34Jeremy: That's okay with me. I've done that with other ticket systems and I just estimate as good as I can.
     35
     36Shane: Have a look at link I sent and we'll have a final decision next week.
    3337
    3438== 2010-07-01 release ==
     
    4044Code freeze date?
    4145
     46Jeremy: Code freeze on the 30th in the morning, so 24 hours.
     47
    4248----
    4349
    4450"New work stoppage" date?
     51
     52Jeremy: Actually for finishing coding, I was hoping we could finish on the night of the 26th.
     53
     54Shane: I was thinking a week...
     55
     56Jeremy: Today is the 15th, which means we have only a week to finish up before the reviews.
     57
     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.
     59
     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.
     61
     62Jinmei: The more important thing is to perform code review more regularly, rather than at the end of the development period.
     63
     64Michael: That means you have to assign the code reviews at the very beginning just like you have to assign the work.
     65
     66Shane: At the end of your work day on 2010-06-24, no more code submitted for review.
    4567
    4668----
     
    4870Requests for help, questions, and so on
    4971
     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.
     73
     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.
     75
     76----
     77
     78Kambe: I have one request for statistics. Ticket #170 is ready for reviewing, so please assign someone as reviewer.
     79
    5080== Architectural Discussion ==
    5181
     82Library rename: libdns -> libdns++
     83
     84*Resolved, libdns is now libdns++*
     85
     86----
     87
    5288gprof, profiling in general
     89
     90Shane: I think just the process time is not useful.
     91
     92Jinmei: I think DTrace is one thing that is useful for this sort of thing.
     93
     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.
     95
     96Jeremy: It doesn't have wall time.
     97
     98Shane: Which version of Solaris are we running?
     99
     100Jinmei: MacOS also supports DTrace.
     101
     102Jeremy: We're running Solaris 10 on Sparc.
     103
     104Shane: Does FreeBSD also support DTrace?
     105
     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.
    53107
    54108----
     
    56110Python testing stat
    57111
     112Jeremy: I sent a list to the mailing list on some of that, and we have some projects that are missing Python testing.
     113
     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.
     115
     116Jeremy: There are 6 or 7 Python scripts that did not get any unit testing. Do I need to open tickets for that?
     117
     118Shane: I think that's a good idea.
     119
     120Jeremy: I won't create tickets for each script, but for each module/component.
     121
    58122== A.O.B. ==
    59123
    60124Larissa talking to various ISP's at NANOG this week about their DNS needs - especially on the recursive side.
    61125
    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.
    63127
    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.
     128----
     129
     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.
     131
     132----
     133
     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.
     135
     136Michael: Not useful for us.
     137
     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.
     139
     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.
     141
     142Jelte: I used kcachegrind to make graphs earlier.
     143
     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.
     145
     146Shane: That's a good point. I think the answer is "yes".
     147
     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.
     149
     150Shane: I have used valgrind, and when it works it's great. I would rather do that.
     151
     152Jinmei: External tools do not necessarily catch all memory leaks. Also, carefully written C++ is much better about memory leaks because we can encapsulate.
     153
     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.
     155
     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.
     157
     158Jeremy: Noted!