BIND 10 Team Call




Signing Now Easier? (Shane) 2 minutes

Shane can now sign release tarballs. Hopefully this will make the release process easier.

Hardening Sprints 9 minutes

Jelte wants hardening sprints. Lets discuss it.

Shane: What does a hardening sprint look like?
Jelte: We have a lot of leftover stuff that gets dropped because we are working on more important things. Each time that is a choice we make and a choice we would make every time but the things that get dropped are accumulating. It doesn't seem like there will ever be an end if we don't change this behavior. I would like to see us do sprints that let us catch up.
Stephen: So a sprint with just bug fixes?
Jelte: Mostly.

Jelte: I would like to have more opportunity for people to select which ticket they are working on. Everyone can propose things, but these proposals are often dropped. I have a number of tickets that I have wanted to fix for a long time.
Jinmei: I don't understand what the specific proposal is.
Jeremy: How often do we do a sprint? And does it mean no new features? And will it slow down our progress?
Michal: I don't know if we can say that it will slow our progress because we need to do these things anyway.
Stephen: We've got lots of little annoyances. My feeling is that unless someone is desperate for new features, they will notice annoyances more than new features they never use. It will allow us to add a bit of polish and make it better.

Jelte: The standard approach is we do 2 sprints before the release, then the 3rd sprint you fix things.
Stephen: I would say that the emphasis on performance is hardening, since it is a non-functional requirement.
Jinmei: But it's adding new code.

Jinmei: I think it's a good idea in general to have some focused time on something we forgot. Especially a bunch of smaller things.
Shane: There is no shortage of these things, but I think if we made an effort to address them that they would get done very quickly.

Jinmei: How exactly to do this is a question, and I don't have an idea about that.
Jelte: I guess a format will be proposed by one of us and we'll have to try one.

Shane: Maybe we can make the next sprint a hardening sprint.
Jeremy: That would be useful.
Jinmei: At the end of the project year I'm afraid we have something more urgent for the release. I think it's better to do it after the release, like Jeremy said.
Stephen: Possibly, but what features do we need to implement?

Shane: Out of time, maybe do at the sprint planning?
Jelte: I can try to give a concept with specific tickets or something.
Jeremy: So an e-mail in the next 2 days or so?

Design(s) for Zone Loading (Shane) 6 minutes

I think the requirements for zone loading are good enough, so we need to proceed on to the design phase. I want to discuss how to do that. We should discuss the user interface / admin management for this also.

Jermey: Design document did not talk about user interface, using bindctl for example. We have an existing interface in bindctl.
Shane: I thought those were design decisions, but maybe those should be requirements.

Shane: Had discussed design committees or design meetings, did we ever have these?

Michal: E-mail if simple, call if not?
Jelte: Idea was 2 or 3 people would come up with design, then mail to team, then have group call to discuss it.
Shane: Shall I send a call to the list? [okay]

Jelte: Also had a way to assign tickets for this. Assign someone as the shepherd for this.
Shane: Maybe we need to define a handoff from requirements to design for that.

ChangeLog document final result (over all picture) 10 minutes

Sometimes we have multiple ChangeLog? entries for related tasks, but the reader/user can't recognized that when combined it provides a new important change or feature. We need to keep track of what the real completed goal was and mention it in ChangeLog? too. Maybe this could be helped by having a meta ticket for the final result and to close them a ChangeLog? entry (or review of previous shows is adequate) is needed first.
(would it also be an option to have a second 'management summary' changelog? or are we simply making the current changelog less lowlevel?)

Jeremy: Hard for users or developers to see the big picture. We need to have some way to show this. We sometimes have meta-tickets that track other tickets. Maybe we should have a review of existing changelogs or a new entry that finalizes the whole solution.
Jinmei: I think the changelog itself is for basically logging, and it's not designed to provide a higher level structured view of what the new features are.

Shane: Here's an example of one project:
Maybe Jinmei is right and we need to provide some other documentation for this.

Jeremy: I look at goals page, then I review changelog entries, then I review documentation, and I have a guess, and I have to ask a bunch of people, and people remind me of things that were added. It's pretty ad-hoc.
Jinmei: Basically we should have some key features for each release, concept-wise. I think it is not so difficult to find a way to do that. It might be a meta-ticket or a wiki page. I don't know what is the best way for that right now.
Jeremy: A wiki page or a meta ticket that tracks each release is fine, should be easy.
Jinmei: Or something related to sprint management pages.
Jelte: That might also serve ourselves, in keeping track of what we have still not done.

Jeremy: Tomorrow I'll make a wiki page for the upcoming release, then I can share the wiki page and we can provide comments and update it.

Version in the master (Jeremy)  5 minutes

Maybe just call it generic "master"?

Jeremy: We have a version that is the datestamp. We mostly ignore it in the "master" tree. Lately we've had a few outside users who thought they were using an older version in git. Maybe there is a way to automate it so it increases automatically. The simplest thing is to not give it a version at all and call it "master".
Michal: It would be nice if the version contains the hash from the git.
Jelte: We don't want so use a hash for directory names.
Jeremy: Once a month or every 2 months I update it. The tarballs always have it updated every time.

AP: Shane to make ticket to investigate setting the version from git hash

Throw in seperate method or assert? (Michal) 4 minutes

Ticket #1568
Another way to make throw, which is not as fast as assert(), but more clean.

Jinmei: My suggestion is to merge the fastest for now, and then later measure the total benchmark with and without the assert() and see if the total difference is significant.

Cooperation with BIND 9 (Shane) 5 minutes

SQL data source schema (Jinmei) 14 minutes

  Jinmei: Whether we want to do major changes, and whether we should introduce incompatible changes one-by-one or do one big change to avoid users having to update schemas.
Jinmei: And also what we should do with ticket #324.

Jelte: Does it currently contain anything but index creation? [no] We can merge that without being incompatible? [no, it requires schema change]
Shane: I think we should merge #324, since it is so bad the system does not work.
Jelte: Regarding incompatible updates, we should group them. Ideally we should start out with a full new design.

Shane: Propose multiple data sources with different schemas.
Jeremy: I agree.
Shane: If we decide to go with a new, high-performance data source we need to do some benchmarking and testing and things like that.
Jelte: In the end I think we will need some sort of translation so people can add their own databases including SQLite, it would be nice to provide as much defaults as possible, so it might be good to have different versions of SQLite.

Jelte: Do we want to do this before we improve the performance of the existing one?
Jinmei: What kind of improvements?
Jelte: Support/implementation of multiple SQLite data sources, a general database abstraction layer where people can define their own queries and things like that.
Shane: So for example a simple, easy to understand one, and then one that is optimized.
Jinmei: Hard to provide optimized lookups with SQL backend for DNS lookups.

Jinmei: Another possibility is that we may be able to provide a faster database backend if we can ignore cases like wildcard matching. So it may make sense to develop some limited feature but higher-performance database backend.

Shane: Maybe put on agenda for face to face meeting.

Jinmei: Complete #324?
Shane: Yes, we have to.

(Missing) Glue in zone files 5 minutes

Should we look for glue in other zones or datasources? (makes additional data lookup more involved again). If not, should we warn or error on missing glue?
(Came up in #1608)

Jelte: If you have a parent zone and a child zone and the parent does not contain the records for the in-zone record.

Jinmei: What should we do when we handle incoming queries. Do we eventually want to include out-of-zone glue (like BIND 9)?
Jelte: It is dropped anyway, so I don't think it is useful.
Jinmei: Right now, completely out-of-zone glue is useless. In-bailiwick glue is not difficult to provide. What should we do if the server also has authority for the child zone? Look in child or not? What should we do if DNSSEC is more widely deployed? Even complete out-of-zone glue may be usable with a signature.

Bikeshed: Operator Overloading in C++ (if time available)

(as we didn't have time for it in the previous meeting)

time not available! I have specific proposals:

Last modified 6 years ago Last modified on Mar 13, 2012, 4:18:31 PM