wiki:WeeklyMinutes20100601

Attendees

Shane
Likun
Jerry
Feng
Jeremy
Jelte
Shawn
Larissa
Kambe
Jinmei
Fujiwara
Evan
David

Action Point Issues

Probably should move some action points to Trac tickets.

2010-06-03 release

Decide at end of phone call whether we do 2010-06-02 or 2010-06-03.

http://tinyurl.com/3xn586b


State of current reviews

#175 and #176

#167 - no tests (Shane says MERGE ANYWAY), inet_pton() vs. getaddrinfo() issue

Jinmei: [ too quiet to hear, from Jabber ]

(23:20:47) jinmei: the getaddr thing is just a comment.
(23:21:06) jinmei: the code hasn't actually been reviewed.  I just made a comment on a tip of it.
(23:21:18) sar [sar@jabber.isc.org/Laptop] entered the room.
(23:21:26) jinmei: I basically oppose to lowering a bar of test requirements.

Evan: Jinmei hasn't actually reviewed the code, which makes me more nervous. But I'm fine either way.

Shane: I guess, for my own personal needs I can just apply the patch.

Evan: Maybe, it may need to be re-merged...

Shane: In that case, lets not merge it unless we have tests and review.

Jeremy: These comments need to go at the end of the ticket.

#109 - merged, now in #168

Jeremy: Did not say which component errors came from. Even after merging I still had this problem.

Evan: I added b10-auth, and then in Trac #168 all of those error messages got removed, so there are 2 messages left that do not have the "b10-auth" string and those have been changed. Most of the error messages were in code that no longer exists.

#192 - Shane has no time, Jinmei may be able to do it

Jinmei: I am not optimistic, but I am happy to have a look.


Other outstanding issues

Likun: I think we need more time for review.

Shane: Maybe we need some time before a release just for review - like 1 week.

Jinmei: We are too optimistic about our planning. People do not normally think about the review cycle. Realistically we cannot make it without this. In the previous face to face we only talked about development. I don't think we can do this 100%, so this is something we can improve.

Shane: I thought about delaying the release by a week, but since we release so often, I think we just have to miss the features.

Jeremy: I agree.

Jelte: +1

Evan: As a matter of policy I think we should have some features that one would slip for, you just need to know what they are.

Jeremy: I agree with Evan, but for right now these are basically just snapshots. And we have many changes!

Jelte: And it's not that bad to merge stuff at the more beginning of a sprint.


Things that did not make it

  • setuid() by boss process

Jeremy: Some of it could be done now, like cmd-ctl, cfgmgr, and so on.

Shane: Should have sent to list, so bad style on my part. :(

  • NOTIFY kick-off xfrin
  • Non-Boost Python wrappers for DNS library

Jelte: it works but it isn't done, but has no documentation and needs integration and I didn't find out how to do some stuff until today, so needs some more work

  • Python logging
  • loadzone changes
  • hotspot cache

Jinmei: Do we need to provide ext/asio? Right now we have ext/asio, autoconf assumes that this code is there. We add the include path to this directory. asio is not an optional feature any more. If we remove the ext directory I think we need to revise the configure script so it can identify where the asio include files are.

Jeremy: As of now I need to adjust the makefiles a little bit to make sure the ext/asio is included in the tarball. Some of the autobuilders are failing. That's fine, that's easy. In the long run, do we want to include that? Also for ext/boost... I think we should just get rid of it.

Evan: That seems to be consensus. Unless we plan on shipping headers... but if we're going to do a half-assed job we should probably not do it at all.

Jeremy: Even if we did provide them, we haven't seen any problems with various versions of boost, so I don't see any reason.

Jeremy: Between us we've used 7 different versions of boost and not had a problem.

Shane: For now we should get rid of it.

Development Bits & Bytes

Do we continue to provide ext/boost?

Jeremy reports:

   Note that the two releases never shipped with ext/boost. It was 
   incomplete and we had seen incompatibilities/conflicts.

   I was told that Solaris build needs boost headers (not from 
   ext/boost). I don't need details yet. 

(See above.)


When to update ChangeLog?? Any policy? It is very incomplete.

Jeremy: This is based on the new file that Jinmei proposed. It has not been maintained at all. I have a patch to try to add old change entries that have been previously written into it. We need to decide how to proceed on with this.

Shane: Logically when we commit to trunk we would update this.

Jeremy: How often are we going to add or update this?

Jelte: A more general thing is "when you resolve a ticket".

Evan: I was going to say that.

Evan: Changelog legend does not have "cleanup".

Shane: We can add that.

Shane: There are 18 closed tickets for this release. Do we want to ask people to go back and add this?

Jeremy: Last time I did "svn log" and wrote a sentence about each of them. Playing catch-up isn't fun.

Shane: In DHCP we put changes into the branch, right?

Shawn: Everything goes into the release notes.

Evan: In the RT branch, rt####, and you are working in there, do you write the change to the release notes in that branch?

Shawn: I do. You write up what you are going to put into the main release notes, so it is clear what you are fixing.

Evan: It was easy in DHCP, you don't have to worry about merging in the wrong number. Some people in BIND 9 do that, but most do not.

Shawn: There is one other issue with that. If you check out a branch and something gets cut, the release notes have some little issues.

Shane: We could update our review policy to insist that the changes must be in the changelog before the review.

Jeremy: On a related note, some subversion commits refer to a trac number. Going back to a trac ticket is difficult.

Shane: I am guilty of that. It seemed like duplication, but if we are going to use the information I can do it.

Jinmei: I think if it is for the developers then I think it should be pretty easy. OTOH, if we copy & paste the summary then that might be inconsistent.

AP Shane to send mail to bind10-dev proposing we update changelog before asking for review.

Shane: Jeremy, will you go back and make changelog for this release?

Jeremy: Yes.

Jeremy: I was planning on including the subversion history. But that's not useful without Trac.

Shane: For now not meaningful...

Jeremy: Because I have the entries from the last release... I guess I'll renumber them... I didn't know they had significance.


Should we ship ext/asio? Should we just have the admin install asio separately? It is available as a Debian package as an example. Do we want to maintain this in our own source?

(see above)

Future release planning

Proposed remaining releases in 1st half of Y2:

https://lists.isc.org/pipermail/bind10-dev/2010-May/000965.html

Shane: This will be on the call next week, updated based on what actually made it into the release.

"Too Hard" Topic: Offline configuration & system access

  • How do we load a database when BIND 10 is not running?
  • How do I look at or change configuration when BIND 10 is not running?
  • And so on. :)

Jelte: There is at least also changing configuration for modules that are not running. Which is possible, but we can do better.

Jelte: What I think we need to do is abstract some of the configuration away from the configuration manager, so it can be used by other tools directly, and then add a layer that checks if the system (or a specific module) is running, and if not fetches/stores those itself.

Shane: Would this be something the config manager also used?

Jelte: Yes, that's why the first step is to abstract it away. So configuration management would be more of a library, and the configuration daemon would be more of a client of the library.

Shane: Of course commands will not be possible. There may be configuration that is only possible at runtime...

Jelte: Those should be commands not configuration then.

Jinmei: Is there a consistency issue?

Jelte: Probably.

Shane: Can a module refuse a change a runtime.

Jelte: That was the original idea, but maybe we need to drop that...

Jelte: We may want to check changes when the system start.

Shane: Or we can roll back to the last known good config.

Likun: Also need to think about the bind9 configuration file. If you want to port from BIND 9 to BIND 10... if it's very big, we don't want to create it from 0, so maybe we want to load those rarely, and then do some change.

Jelte: There are probably multiple devils hiding in the details. There are probably reasons other systems don't do it like this.

Architectural Discussions

(possible) How to avoid multiple xfrout processes running at same time?


(possible) Moving functionality out of .py.in files


(possible) Running stuff from the source tree

Jelte: We do need to have discussion on the list!


(possible) Privileged socket creation

AOB

Jeremy: We didn't set a time for code freeze today. Does anybody have specific big features they are going to try to commit to trunk within the next 12 hours?

Evan: Not to commit to trunk? Have we decided for sure that hot cache is not going in this release, or is Jinmei going to look at it?

Jinmei: I will have a look at it. I think it will be the next release. It might be multiple issues.

Shane: So we'll wait a few hours and see.

Jelte: I merged everything I wanted to merge in yesterday.

[ specific time negotiated ]


Jeremy: Are we going to talk about Jinmei's experimental code?

Shane: I think we have to! We can talk about that next Tuesday.

Last modified 7 years ago Last modified on Jun 2, 2010, 3:40:09 AM