wiki:WeeklyMinutes20100415

Attendees

Jinmei
Likun
Jelte
Fujiwara
Shawn
Michael
Jeremy
Hankins
Shane
Larissa
Kambe
Evan

AP from Previous Weeks

  • Jeremy to investigate logging bot for Jabber room

Jeremy: It's been logging for a week now. Once it's all cleaned up I'll post a message about it to the list.

Evan: Are we planning on rolling it periodically or keeping it forever?

Jeremy: I don't care. It makes a new file every day.

Jinmei: I think it will be archived indefinitely. We may want to refer to it in two years.

Jelte: We might want to have a search function?

Shane: Also put this on the wiki?

Jelte: I would propose that we not make this public.

Shane: Not protect with passwords, or just not advertise?

Jeremy: Yes, it will be password protected.

Likun: Can we e-mail the login to everyone?

Jeremy: Yes.

Jelte: In general I agree with Michael that we should not do anything really important on the jabber.

Shane: We already agreed, all decisions are made on the list.

  • Michael to write blog entry about SQLite3

Shane: Keep as action point?

Michael: Remove it, and make a possible list of blog entries.

Jeremy: We have a URL for that.

Larissa: Doing next issue of ISC newsletter, so if you have anything you want to go in there let me know by the end of tomorrow. It doesn't have to be written by end of tomorrow, but I need to know about it.

Shane: When is that going out?

Larissa: The hope is that it will be done before I leave for China.

  • Shane will mail proposal about new categories and milestones to list.

Shane: Not done.

  • Michael to write mail with motivation & description of DNS conformance test.

Michael: Not done.

  • Jelte to write blog entry about Python wrapper.

Jelte: I do want to write that, but wait until we have a final decision and something more complete.

  • Jeremy to send mail about code review & use of trunk.

Jeremy: Need to document how to handle very minor items - commit without a review. Need to figure out what to do for other minor reviews, like a few lines of code change. Do we want to create a branch for that? We just need to document a step for that.

Jeremy: The goal is that everything we commit is reviewed. And the commit message should indicate that it is reviewed.

Jelte: Doing it in the commit message gives us a chicken & egg problem. Usually when you commit something it isn't reviewed yet...

Jeremy: Maybe provide a patch if it is small? Or we could have a "testing" branch that gets real development merged in frequently. Not required, but some place to make changes....

Jelte: Probably more overhead than we need.

Jinmei: There will be many not-trivial but not-so-big patches...

Michael: Also have to be careful about what is simple...

Michael: The way I've seen other projects do this is that you mail a patch to the mailing list and if nobody replies then it is okay.

Evan: I don't want to go far with this, but I would like to point out that we have been making strange adaptations of our workflow to the tool rather than the other way around.

Shane: Will be on the face-to-face agenda. Maybe you can send a teaser to the list?

Evan: I will.

AP Evan to send mail to bind10-dev about this.

Michael: Everyone loves git.

Jelte: Everyone I know talks about how great git is.

Michael: Some concern about git making forking easier.

Jelte: A distributed system will always have that.

Michael: There is an issue of git which is that it goes from having a master repository to 45 different options for the repository. Difficult for a newcomer.

Jelte: I don't think it is Subversion... we still need an authoritative tree. The problem now is that we have a very incomplete one. We need to have stuff reviewed and pulled into the branch, and I don't think changing systems will solve that problem.

Jinmei: I agree. I don't think this is a tool problem.

Shane: I mostly agree that it is not a tool problem. But we do constantly have conversations about how to structure our Subversion to match our situation.

Evan: We have it over and over and over. I think we have a workflow problem but part of that is that we are not adapting to the tool.

Michael: Other people don't have these problems...

Evan: I've googled and other people do seem to have these problems.

Michael: We may lose history if we switch tool.

Jelte: I think there are good tools for conversion now.

Jelte: We still have a workflow problem we need to figure out.

Shane: This will be a part of a larger discussion at the face to face meeting about tools. For example maybe Trac's ticket system is too primitive and we need to use RT.

Jinmei: If we do that, I would like to see a specific proposal.

Michael: I have another question about ticketing system. Does it have to be something we run?

Larissa: I have anxiety about us moving to a new ticketing system that is radically different from a system that we use.

Michael: RT is not designed to be open.

Shane: It depends.

Jinmei: The short-term issue is what we do right now on the trunk. It might be good to continue that discussion on the mailing list.

Y2r01 status

  • Ticket reviews (Jeremy)

Shane: How to resolve these tickets? Just go through one by one?

Jeremy: Part of the problem is a lot of code was reviewed, and since then the code has changed a lot. Jinmei's doing a really good job asking for reviews of everything he does. Other than that a lot of people are touching code here and there and I don't know that it has been reviewed.

Jelte: I have two branches that can be reviewed. I don't know if they are in this list. But we could walk through it. I know there are least two in there that I added to review today and closed the tickets. And there is one that I could but the source material hasn't been reviewed yet (the library that is patched hasn't been reviewed yet).

Shane: 25 on this list. Jeremy & Shane will stay on after the call and go through the list of tickets.

  • Python wrapper research (Jelte)

Jelte: Most of it is in the mail. I would like people to take a look at least at the mail, and preferably also at the code.

Jelte: I tried the new Ubuntu beta, and it still doesn't have boost-python for Python 3, so I'll have to install manually to compare to what we have now.

Jelte: I took a quick look at SWIG, but it doesn't really handle all of our uses of STL well at all. It makes SWIG objects that have the name "stl-string", and we'd have to write converter functions for them.

Jinmei: So it's not so different from the scratch version you are doing?

Jelte: Yes. There is the advantage that it can export to multiple languages?

Shane: But we'd have to write hand code for each of those languages?

Jelte: I've only spent like one or two hours getting something to work. I think if we keep track of it by using a unit test and having manual stuff is only hard once. It really speeds up once you've learned how to do it. But it is a lot of code.

Shane: Do you think we have enough information or do we need to spend some more time on it?

Jelte: Would like to spend some more cycles on Boost on my system. Then we can discuss it with what we have now.

Shane: Did you do any benchmarking?

Jelte: No.

Jinmei: You seem to think about the possibility of code generation from the C++ to the wrapper code. Would that be possible?

Jelte: I did mention this somewhere, and I think it's going to be the 80/20 rule. It looks really easy, and most of the stuff really is easy to generate, but then you will run into a problem and it will probably break down. I think we shouldn't use any generation at all if we have to add after that. But as long as the API is reasonably stable it shouldn't be much of a problem.

Michael: The big concern is what happens when we have a new library or the API does change. What is the incremental cost of that? Even if we don't automatically generate it, then we need a tool to verify we have generated. For example, in BIND 9 for Windows we need to have a list of everything exported.

Jelte: At NLnetLabs we had an automatic test for that. It is a valid concern (when something is added). But it is a concern for anything because we always have to define what we export.

Michael: I suspect people will want Perl, TCL, Ruby... if we have to limit what we do in our code but it allows us to use a generator then I think it might be something to consider.

Evan: That's a good point, but it might be a little "cart before the horse".

Michael: I've done a hand wrapping for Perl for libdns and libbind, and it's not fun to maintain.

Jelte: One of the problem is that if you don't continually keep in mind that you need to update every single change, at one point you get behind.

Michael: Python 2 and Python 3 have different wrapper stuff. Ruby 1.8 and Ruby 1.9 have different stuff at the wrapper level.

Jelte: What you do with SWIG is define a .i file which include the .h file, and then everything you want to write you do in a C++-like syntax, and then anything else you write in a custom handler. Since we use STL so much it might be a lot of work too.

Jinmei: I think another important point is the dependency. If use any external tool like Boost.Python or SWIG, it will require a dependency on a binary library.

Jelte: Boost.Python does, but I only think SWIG needs an external library if you want multiple modules that need each other (for type conversion).

Jinmei: I think we should avoid binary dependency in the initial phase of the project. Very few people will try it.

Michael: Unless we do it as a tarball.

Jinmei: I remember you proposed that. I don't know if it works well. But it is a possibility.

Jelte: I know two people who downloaded the release but stopped while trying to build it.

Shane: Which dependency?

Jelte: One was 140 megs of packages for Boost.

Michael: I had one person complain bitterly about Python 3.

Michael: Do we want a quick tutorial on how to write a wrapper in Python at the face to face?

Jelte: Sure.

Next Week's Release

Jinmei: We should discuss the release. I'm not certain whether this will be based on the trunk or the reviewed branch. Which feature will go into the next release. Do we have xfrin and xfrout and things like that. What exactly we are expected to do for that release. Do we need to write more documents? Or doing coding for the next couple of days.

Jeremy: The first thing is, my plan is not to use the REVIEWED branch. Right now it is just to keep track. Eventually the trunk will be where we keep reviewed code.

Jeremy: xfrin will be included, with documentation on how to use it.

Jeremy: xfrout... I do not know. Simply because I haven't documented it yet.

Jinmei: I'm concerned about the overall quality of the code and lack of test cases and all that.

Michael: Should we write documentation and test cases for xfrin.

Jeremy: Test cases for xfrin would be great.

Shane: Is there a coverage report for the xfrin.

Likun: Haven't added too much test code. I think I can add it in a couple of days. But I don't know if I did if it will need to be added to the release person.

Shane: I think having you add test cases is an excellent idea.

Shane: As far as review... it's a ticket like the rest?

Jinmei: Assigned to Likun himself, so not sure if it is a review request...

Likun: Did you review the code for xfrin.

Shane: I don't think anyone has reviewed it.

Jinmei: I took a quick glance, but have not given a complete review.

Shane: If we spent Friday & Monday writing tests, then on Tuesday reviewed it would that work Jeremy?

Jeremy: Yes.

Jeremy: I'm also working on missing copyright. This is a very long list.

Jeremy: I'm also going to be writing a CHANGES file manually to cover the last few weeks. Maybe we can discuss the style in the face to face after the fact.

Jinmei: Test case should be provided before asking for review.

Jinmei: What about the other part of the trunk? I've made relatively trivial changes to the trunk. Some of them have not been reviewed.

AOB

Likun: Is there that somebody needs some help with travel to China or some help with the face to face meeting? If so send us an e-mail and we will try to help you.

[ Discussion of arrival/departure ]

Evan: Are we organizing hotels?

Shane: Jin at CNNIC has organized hotels. I will send those around.

Larissa: How will we pay for these thing?

Shane: Good questions. I'll ask.

AP Shane to find out how things get paid for


Jelte: If you only have Internet access during the day next week, we may need to switch the time of the meeting around. If we have to do that I would like to know in advance so I can reserve in advance.

Shane: Likun let me share his phone?

Likun: Yes.


Jelte: I am going to co-write a paper for LISA '10 for enabling DNSSEC in organizations.

Last modified 8 years ago Last modified on Apr 15, 2010, 4:34:40 PM