Changes between Version 1 and Version 2 of WeeklyMinutes20100608

Jun 8, 2010, 4:03:09 PM (7 years ago)



  • WeeklyMinutes20100608

    v1 v2  
    1 = WARNING: Meeting not yet done! Minutes may make no sense!!! =
    31== Attendees ==
    9 Feng
    11 Jelte
    12 Shawn
    14 Kambe
    15 Jinmei
    16 Fujiwara
    18 David
    2117== Action Point Issues ==
     19Nothing to discuss.
    2321== Mascot contest: extended! ==
    2725== 2010-06-03 post-mortem ==
     27Shane: Not enough time for review.
     29Shane: Estimates were optimistic.
     31Shane: Automated builds broke.
     33Shane: Realistic release planning.
     35Jeremy: Because we were assigned tasks in Beijing, some were not clear, some developers were not told what their tasks were for 1-2 weeks, so we had 1-2 weeks dead time right at the beginning of our cycle. Everyone needs to be clear about what they should do up front.
     37Jelte: General problem in that some information got lost in translation from sticky notes to task list.
     39Jeremy: Had a holiday weekend immediately before our release - did not realize at first. Many developers were committing like crazy over the weekend, so we had a huge crunch of new code committed at the last minute. We need a plan to commit the code earlier. "If it's too late it's too late." Adjust for holidays, and also adjust for weekends.
     41Michael: We'll make sure we don't pick holidays. If we had a calendar with these things on it, it would be awesome and we would know these things.
     43Shane: Should we put a calendar page on the wiki?
     45Michael: I don't want two.
     47Shane: I forgot there was a mailing list change for PGP. Jeremy sorted it out.
     49Jelte: We got a bug report! Someone had a compilation problem - missing a dependency we did not check.
     51Jeremy: We have a workaround for that now. We just need to commit it.
     53Shane: I'm happy with the release. My only concern is we pushed a lot of stuff over to the next release...
     55Jeremy: I can't remember the details, but right before the release Jinmei noticed that xfrin had stopped working. I'm not sure because we didn't have a good system to test that automatically. I was thinking we need to make sure we get more tests so we notice these things. I don't know the details of that.
     57Jinmei: In this particular case, this is a coverage of test issue. I added more and more unit tests, but the problem is in the xfrin actually communicating with a real server. So testing for these kind of things is not easy in a unit test framework. To fix this kind of problem we need a high-level test like the system tests we do for BIND 9. Maybe Michael's Cucumber thing might be useful for that.
     59Michael: I need to get those going again. Unfortunately I moved the Subversion repository over and I made it with too new of a version. Maybe the git one will do and we won't worry about history if we have to switch to another version control system.
     61Jeremy: I do have a few shell scripts that I use to start BIND 10, do xfrin, and a few queries. So maybe I would have seen this.
     63Jinmei: Starting the processes did not help in this case. We need to do more than that - perform actual zone transfer.
     65Jeremy: Yeah I do do that. I scripted this.
     67Jinmei: I think this is not an architectural issue in our development or testing. As we add more unit tests and system tests we can prevent these things from happening. We cannot 100% eliminate the error, but I don't think we have to do anything specific for this error, except that we need to be serious about testing in general.
     69Shane: I think we need to assign this someone. Probably not for next release but for the release after.
     71Jinmei: Another thing is we should start eating our own dogfood. I think we are almost ready for that. It is easier to find these kind of things. It does not eliminate the need for unit tests or other tests.
     73Michael: Have ISC ops run this?
     75Jinmei: No, run it ourselves, like
    2977== 2010-07-01 planning ==
     79Shane: seems to be a week of time between releases.
    3181Available time
     83Shane: Look at e-mail I sent. Let me know if estimates for your time are incorrect.
     85Jerry: I think for Python logging, better to review it before planning for more.
     87Likun: Jerry planned on providing document for the zone manager when the Python logging is done.
    3995Additional work
     97Shane: Should we assign tasks now, or will that not work?
     99Jinmei: I think that is better by e-mail. I can think of several other things that need to be included. For example some features for the DNS message class for the purpose of XFR. These things are minor but we will probably miss something if we do this on this call. So probably better to have time to think about it and then send to the list to discuss.
     101Shane: Can we do that within the next couple of days?
     103Jinmei: Probably. This may not be true for others. If I cannot send a proposal within a few days then you can select something and assign them to me. In any case I will not be available until next Monday.
     105Shane: Okay we'll do it that way. At the next call we'll have a definitive list of tasks for next release.
     107Likun: I don't think any of these tasks can be finished before the next release, but we need to start it now.
     109Jinmei: Learning lessons from the previous release... I think we need to think about how to make more accurate plans for specific work. In many cases these estimates are not correct. One thing we could do is that we should record estimation and also record the time spent on that work. And then review that. Once the work is finished we can review the difference between work and actual time and use it for next time.
     111Michael: Are there fields on ticket for estimated and actual time spent.
     113[ discussion ]
     115Shane: Let me think about estimation and see if we can apply something for this sprint.
    41117== Architectural Discussion ==
     121== A.O.B. ==
     123Jinmei: Part of my experimental work I wrote a framework for micro-benchmarking. Maybe we could use this for other purposes. Perhaps I can make a branch only for that part and get it reviewed.
     125Shane: This makes sense. We talked about this at the face to face meeting, right? If you have written something you think might be generally useful I would like to see it.
     127Jinmei: It is not so general. It is a template that calculates the start time and end time and average. It's not so different from what you would write by yourself. But assuming we do many other microbenchmarks for many other things it may be useful in some cases. I'll make a branch and try to get it into the trunk.
     129Michael: Everything will need a start/stop recording and report some value.
     131Jinmei: The framework is just a template to do that.
     135Shawn: Did you see mail about DHCP users list? Someone was saying "wouldn't it be nice if we upgraded DHCP to be more recent?" I wasn't sure if you or David or I should respond to that.
     137Shane: It can't hurt to let people know what we're doing in that area.
     139Shawn: Maybe even someone willing to sponsor something or other.