Changes between Version 1 and Version 2 of WeeklyMinutes20101012

Oct 12, 2010, 3:58:20 PM (8 years ago)



  • WeeklyMinutes20101012

    v1 v2  
    2324== Team restructuring discussion ==
    25 I'm not typing!
     26Shane: Apologies for not sending plan. Was delayed working on senior management approval. Have that as of an hour ago, so mail will be sent.
     28We will have BIND 10 team meetings every 2 weeks.
     30The other weeks we will have a A-team meeting and an R-team meeting. These must happen on separate days. The suggestion is to have one on Tuesday at this time, and then a different one on Wednesday at the same time. This will be discussed via e-mail.
     32Larissa: Discussing difference between sprint planning and sprint retrospectives. Link sent to Wiki (2 documents... one PDF looks weird so trying to fix).  ''Scrum Primer'' available in English, Mandarin, and Japanese. Explains this idea in detail.
     34Shane: Larissa & I discussed user stories. This is a spreadsheet that will get sent around.
     36Shane: Release cycle will begin next week. Then we have 2-week spring, then another 2-week spring, then a final 2-week "hardening" sprint, which will end with a development release like we've done now.
     38Stephen: Will the release begin next week? Does that conflict with the IETF?
     40Shane: First sprint should not... we don't have *too* many people going to the IETF. (Stephen, Jelte, possibly a couple more.)
    2942== Technical issues ==
    3144'''Python & threads (or perhaps threads in general)'''
     46Michal: I discovered that Python threads really run in parallel (on multiple cores). This brings the possibility of more race conditions and stuff like that. Jinmei said that most of the code we have did not expect that it runs in parallel, so it is more naive - less careful locking & stuff. For one, we should never do this, but also as Jinmei said in his e-mail we need to think about whether we want to use threads or not.
     48Jinmei: Most of code might be overstating, but the point is that I've seen many not-so-careful code about multiple thread in the Python code. We could fix it, but it would result in more complicated code (as BIND 9 shows). Another point as I stated is that we have already given up one of the major advantage of threads which is a relatively straightforward way of coding (just waiting on connect, and so on). We usually have to expect more than one event, so we still need to handle multiple events. So I wonder... it might make more sense to just use code without worrying about thread-related issues.
     50Likun: A race condition may happen on shutdown. But for the user in most cases he will shut down a little while later, and this condition will not happen.
     52Shane: More of a general question right?
     54Michal: We want to discuss more generally if we use threads. If we have threads we will run into race conditions often. It was just shown by this race condition, because a test failed so I read the code more carefully. Maybe use a different model (Shane suggests "asyncore") than threads?
     56Jinmei: To clarify my point. The specific bug we are currently having may be minor and only happen in very rare condition. My concern is, just like Shane said, a general issue of how we are coding. Such as sharing global variables, without considering race conditions and so on. That makes me nervous about the possibility of having more serious bugs in the future.
     58Evan: The plan we've always had regarding threads is probably still the right one. Use threads where it makes code simpler, but when we need complicated code for performance we can do it too.
     60Jinmei: One motivation of using Python is code readability. My concern is that if we keep this way of coding, this will be an unfortunate mixture of relatively not understandable code with subtle, thread-related bugs.
     62Jinmei: In the case of recursive server... if it is necessary for performance, we need to be careful.
     64Evan: If it's performance-critical we're probably not writing it in Python.
     66Jinmei: So the recursive server is separate from this point.
     68Jinmei: Others please read my message about my concern, and express whether you agree or disagree or have other ideas or anything.
    3370== Mascot status update ==
     72Larissa: I have had a couple conversations with the guy who drew the parrot that we will be using for the mascot. We will use our style and colors but continue the parrot theme. Then we will "launch" him, put him on the wiki and the ISC site, and we'll make t-shirts and give them to the team and sponsors and so on.
     74The idea with the parrot is: "it's like DNS because you train it to say what you want and then it says it over and over again".
     76Jelte: Doesn't every type of server do something like that? ;)
    3578== Subversion to git status update ==
     80Shane: I officially have the "token" for the Subversion to git conversion. The plan is to take the general plan worked out at the ISC face to face and turn it into a BIND 10 specific plan.
     82Michal: Some comments & ideas on the mailing list. For example using '/' in names to make them readable. Will these be considered?
     84Shane: Yes, these will be included.
     86== AOB ==
     88Evan: Ultimately we are planning on having 2 servers: Auth-only and Both, but for now we will have Auth-only and Recursive-only. There is a lot of overlap in the code for that - essentially identical. "" is almost the same between the two. I brought up how to do code sharing for this. I thought they would live in the same directory and build from almost the same *.cc files. Everybody else thought it should be in a library. I was surprised that everyone agreed on this. Does everybody actually agree on that? Should we make it a style point?
     90It seems more natural to me to do what we do in BIND 9 and build them next to each other.
     92Jinmei: I don't have an opinion. I do not fully understand the issue.
     94Evan: It's really just a style point. We have not discussed this before. If everybody agrees I'll update the style manual.
     96Jinmei: As long as we can avoid duplicate code I don't care much.
     98Evan: The distinction is: Should "src/lib/" be for 3rd parties, or everything shared between 2 binaries.
     100Michal: I think it's too early to think "will we need a public API for this library". The API will change a lot anyway.
     102Jinmei: I tend to agree. We are not yet at the point where we should worry about that.
     104Michal: If we will release it as a binary, then we will decide later if we separate part into public and private libraries.
     108Shane: Installed BIND 10 in production.
     110Jinemi: My BIND 10 server has been working over a month without crashing.