Notes from the BIND 10 call.


2 lurkers

WebEx Take II

Shane: Google Wave: no logging & invitations did not arrive to Kambe

Shane: not a huge amount of work, so we can keep this up if people like it

Action Points from Previous Meetings

  • Shane to come up with chart for timeline...


  • Shane to send some Google Wave invitations (he only has 6 left, so this will not be to everyone)

Trying WebEx? instead.

  • Jeremy to set up automated coverage testing

Jeremy: same as last week. automated coverage testing done on commit to trunk for both Python & C++ testing. Done!... other than the header problem.

Jelte: How does it do the Python coverage tests? Can we also do this from our check-outs?

Jeremy: I sent an e-mail a couple of weeks ago listing the tests run. This is done via a shell script. Not very consistent, so no make target created.

Jelte: Any non-"make test" is ad-hoc and can be removed.

Jelte: I've been working on a .in script to point the tests to a directory that contains data files. I can also do that with a command-line argument. We might want to have a general way to do that. I don't need "on commit" checks, but I would like to be able to run it myself. I think it would be a good idea to come up with a make target later.

Jeremy: I'll point you to the shell script I'm using.

Shane: Is that in the source tree?

Jeremy: No, but I can do that.

Shane: We can put it in "tools" or something like that.

  • Evan to reply to unit tests & include symlink tree mail
  • Michael to reply to unit tests & include symlink tree mail
  • Shane to reply to unit tests & include symlink tree mail


Michael: We haven't even done the things we agreed on at the face to face meeting, like moving "Tests" to a separate directory. Does this discussion depend on this?

Shane: No, I don't think so.

[ Shane talks about the history of this issue for a bit, then asks for input ]

Jelte: my suggestion does make the symlink Makefile hack unnecessary.

Michael: this solves the include problem too, we say #include <foo.h>

Shane: I thought we had #include <dns/foo.h>

Michael: I thought we were talking about reversing the language / module stuff. Right now we have auth/cpp/<files>, so we change this to cpp/auth/<files>.

Shane: *ah*

Michael: don't know if this is more or less elegant, but we have to distribute these separately

Jelte: modules sit in different places for different language implementations

Michael: people working in one language probably find it more complicated the other way

Shane: How do we go about this sort of change?

Jelte: this is really going to foobar some branches again...

Michael: can we delay this until after the release in April since we're close...

Jelte: maybe we should do this just before the release?

Michael: can we do this module by module?

Evan: is it necessary that we do this when there are branches in review?

Jelte: We have a lot of branches, but most of the stuff from that branch is in the trunk marked as "dirty", so we should be able to merge them in, make the change, then check them out again.

Jelte: I'm almost done with my stuff, and was thinking about merging that back and then having it reviewed.

Shane: I think that makes sense. Unless it's going to break some already-reviewed code (which there is none).

Jinmei: Is this only for the coverage tests?

Jelte: The coverage tests uncovered the problem. IMO it is a more fundamental thing.

Jinmei: If this is just for test coverage issue then we should keep the organization clean and solve the test issue separately.

Michael: I don't think it's just the testing. Evan & I have both found the way we do things now annoying. There is an extra "cpp" directory that we always run into. It seems less elegant than having the language first.

Shane: we have a couple things: the "test" directory and this language/module shuffle. Is that going to cause a lot of extra work?

Jeremy: I don't think so. Maybe we should get rid of "cpp" and assume everything is "cpp".

Michael: Where do you put the other stuff.

Evan: How many places will we have 2 language?

Shane: We have 2 now...

Evan: I'm not sure why they have to live in the same structure. Why can't they have different names?

Shane: You mean like "pylib" or something like that?

Jelte: That doesn't change the problem.

Evan: If the Python and C++ directories were peers, you would have to change less.

Michael: src/python, src/cpp, src/ruby, ...

Evan: What if we got rid of the "src" level?

Shane: It's a pet peeve of mine, but "no".

Jinmei: Basically happy with any solution. Normally don't have an opinion about things like that.

Shane: When you put your code up for review, put it in the new layout?

Michael: Who uses "svn merge"?

Jelte: I do...

Jinmei: I also use "svn merge".

Jelte: lcov seems to miss some things... even with 100% line coverage it may not be exhaustive. So we should try to get as near to 100% as we can but no nearer.

Michael: I would rather have it done sooner rather than later. We don't have to do all at once.

Evan: Lets identify all of the currently active branches and have one person do "svn move" inside of each branch.

Michael: That might make me very unhappy.

Shane: How many branches do we have?

Jelte: Better done by merging all back and re-branching...

Evan: My branch is very different from trunk right now.

Jelte: Mine too.

Shane: Lets do this on review for now. If it's not working after the first review or two, we'll re-consider Evan's or some other proposal for this.

  • Jeremy will be writing a blog article about the coverage test

Jeremy: wrote it like 4 weeks ago

Shane: maybe we need an addition explaining the directory moves and then publish it? Otherwise may have to wait another 4 weeks...

Jeremy: some of the code in the trunk is already reviewed, for example src/lib/exceptions.

Jelte: so the first action is to move those already reviewed

Shane: AFAIK all the code for this stuff is still owned by the author

Jelte: src/lib/exceptions has already been reviewed

Michael: msgq stuff has been reviewed, it has a bug in it

Jeremy: lets switch trunk now, and other people can play catch up

Michael: stop working on branches... work on the trunk!

Jeremy: that's what I wanted to talk about today. We're working in so many different places, and we don't know what anybody else is working on. We need to work in the same place or merge changes in frequently.

Michael: as long as the check-in you make works, then it should not be a problem

Shane: before reviewed "fair game". After that, it becomes solidified.

Jeremy: make a development branch where everyone works?

Michael: Why can't we make changes on the trunk itself?

Shane: sometimes you break things

Evan: I would rather use a branch for our stuff because it conflicts with Jinmei's stuff occasionally.

Jinmei: probably true

Shane: maybe Jeremy's idea of a development branch makes sense

Jelte: it's the same problem.

Jelte: I hope this is my last suggestion to make such a big change. I think in the future we won't have this problem as much. Maybe we should just do it in "trunk".

Shane: I'm also not opposed to doing it in trunk.

Jelte: About Michael's suggestion... I kind of agree, but that would indeed mean dropping the review requirement. So I will state that I do not have an opinion.

Michael: willing to have a development trunk where changes get moved back into trunk

Jelte: In that case I would prefer to have "reviewed" and then "trunk".

Michael: the way other people work is "trunk" is where work goes on, then you have "release" branches

Jeremy: just to be clear, parkinglot was a copy to trunk, so parkinglot still exists. I think we need to have a development directory, I don't care whether it is trunk or not. If we have a release directory, everything that goes in there needs to be reviewed.

Shane: Do you want to create a Y1 release branch, Jeremy?

Jeremy: A directory with a README file and nothing else?

Michael: we need the framework there... so some things with a structure. I would rearrange the trunk...

Evan: if we rearrange trunk, lets keep a list of what was changed, so we can do the same thing before we merge it. That's why I suggested one guy do it.

AP Jeremy will rearrange the subversion tree in the trunk to flip module/language meanings.

  • Jeremy to make sure files are automatically checked for copyright

Jeremy: Suggestion was to make sure year matches up. Not done because just because a file is touched doesn't mean we update the date.

Jeremy: I think as it is now it is fine. We don't need to be complicated like BIND 9.

Shane: I don't know what our corporate strategy is for copyright correctness, but I think this is okay.

  • Shane to assign reviews

Shane: Done.

Jeremy: A lot of them are owned by the developer of the code itself.

Shane: I don't know what the status of each code is, so if it is ready for review then please come to me or get a reviewer yourself.

Jelte: review of "auth" is currently assigned to me, I don't know why...

  • Shane to look at releng checklist

AP Shane to talk with Jeremy about this.

Status updates

Shane: this is about the daily & weekly status updates.

CeBIT update

[ Shane talks about CeBIT dreams ]

Development issues


Shane: is lack of DO-bit blocking?

Evan: it is not blocking currently... can continue to work on DNSSEC development without the DO-bit. Clearly will be EDNS0 issues with DNSSEC, so it is important, but I don't anticipate a problem at this point. Sooner rather than later to merge into trunk. Basically have it handling all of AuthQuery? algorithm other than DNSSEC bits. Do I need to do NSEC3 or NSEC3PARAM?

Jinmei: Do we need NSEC3 for Y1?

Shane: I would like to see it.

Evan: Lets plan on that being a separate merge.

Shane: Okay.

Query Algorithm on Wiki:

Evan: Mark reviewed it, and made some corrections which are now on the Wiki.

Evan: I could pseudo-code or flow-chart the existing code to see if it meets the requirements of the algorithm...

Shane: I think I will leave that up to the reviewer...

Evan: who is the reviewer?

Shane: I don't know. Depends on when it is done.

Evan: I was kind of thinking Michael, but maybe we want to avoid group-think.

Jinmei: started thinking about how to integrate RRSig into the RRset class. Tried to review previous discussions, if I remember Shane & Michael discussing this. I couldn't find discussion log. At the moment I just started thinking about this so I don't have any specific idea or opinion about the branch.

Michael & Shane: will try to find logs

Release issues



Jabber alternative?

Shane: do we want a Jabber alternative?

Evan: isn't there a logging plugin?

Shane: pushback from Ops

Jinmei: two issues: 1) history is too short so difficult/impossible to find older discussions. 2) if we have a deep discussion consisting of multiple opinions from various people, taking a day or so, it will be difficult to find the important part of the discussion from the long history. The first issue is a technical issue, and can be solved in many ways. For the second issue I think we need some criteria for which kind of discussion should be in something like a chat room and which should be on the mailing list.

Michael: The general rule is that you cannot reach consensus in a chat room. The problem with a chat room is that not everyone is there.

Jinmei: Right.

Shane: What does it mean?

Jelte: Decisions are made on the list not on the chat rooms.

Jelte: I would still like it logged!

Michael: If ops won't give us a logging chat room, maybe we need

Evan: That's an option, but there is probably a good bot for this...

AP Shane to try again to get logging for Jabber.

This is what we want:

Jelte: Promised Evan that I would walk him through the configuration stuff today, but maybe better to merge the new interface first.

Evan: That's okay.

Jelte: Want this merged & reviewed as soon as possible.

Jeremy: Should we do that training as a group?

Jelte: In fact everything might be lack of documentation. Maybe I should just write a general usage document about this?

Michael: Maybe easier to explain than write the document to start with.

Jeremy: I would put it with your code somewhere.

Jelte: I will think it over.

David: DHCP 4.2.0a2 is almost done.

Evan: Were you going to be implementing our data types?

David: That is the plan, and doing reviews as I can.

Evan: I have to implement some more data types to get DNSSEC working, so I thought it might be better to have you do it...

David: Not for a couple of days.

Last modified 8 years ago Last modified on Feb 19, 2010, 3:44:23 PM