BIND 10 Team Call, 2011-10-04


  • Shane to find someone for feature demo
  • Jinmei to resurrect the discussion about flaw in our reversed name trick to get solution
  • Shane and Larissa to put together a sample of a new page, goal to have it by next release


  • We will not change the daily call times
  • Next BIND 10 release will be 2011-10-14 (Friday)
  • We will also try a Monday release in the future, and compare the results



Following the sun with BIND 10 daily calls

The idea here is for everyone to have two short calls per day, one at the start of their day and one at the end. That way everyone in the team would talk to everyone else on the team every day. This would also help with the next item...

Possible Call Times:

08:00 UTC 
  09:00 UK
  10:00 Amsterdam
  16:00 Beijing
  17:00 Tokyo
16:00 UTC
  09:00 SFO
  11:00 Texas
  12:00 NYC
  17:00 UK
  18:00 Amsterdam 
01:00 UTC
  09:00 Beijing
  10:00 Tokyo
  18:00 SFO

This does mean calls separated by 9 hours on the Pacific Time.

Michal: I could join 1 call a day and sometimes 2. Also I work half-time, which is 4 hours a day, so if a call takes 15 minutes this will be 1/8 of my time in stand-up calls! I don't know if this is well-used time.

Shane: Certainly since you work half time it doesn't make sense to have 2 calls a day.

Jeremy: Dima and I are only on one call a day.

Larissa: It doesn't make sense for you.

Jinmei: I think the motivation is for a good reason but like others I think this is not really a good way to solve that. It seems to be too much overhead, and some people will not be able to make one of them anyway in many cases. It seems to be against the sense of the daily call which should be relatively light weight.

Jinmei: I agree that we should improve the situation, but we should see some other solution than having 2 daily calls.

Shane: Okay, idea withdrawn...

Larissa: One proposal! I liked the idea that if we move the current call in my morning later that we would have more of the group. But nevermind...

Jinmei: Another idea... changing the time of the daily call every week, so that we can have 2/3 of the team join the call each week. So 1/3 will suffer from this situation, but they will join the call on a best effort basis.

Michal: That sounds like a lot of fun to synchronize. ;)

Feature demos

One thing we're missing from Scrum is feature demos. One of the sponsors suggested we do this at the last steering committee meeting, and it makes abundant sense. One possible way to do this is to have the engineer presenting the demo give it on the Monday before our sprint planning, at each of the daily calls that he is in.

Shane: Since we won't be having our extra daily calls, we will need to schedule these on an ad-hoc basis.

Jeremy: Doing in person, the person giving the demo would create a presentation in advance?

Larissa: They would do a small amount of planning but not spend a lot of time.

Jinmei: It seems to assume that we have 2 daily calls.

Shane: That was my assumption but we'll have to do it in some other way.

Jinmei: How long are you expecting this demo is?

Shane: I don't know... maybe 15 minutes? But I really don't know.

Jinmei: And the plan is to do that before the call, right?

Shane: Yes.

Jinmei: I think it's at least worth trying. We may find that it requires much longer time, or that it may be difficult to share the demo in a non-face-to-face way. But we can't be sure, and if it works well then that's very nice.

Shane: Okay, on Thursday I'll try to convince someone to work on a demo.

Shane: Initially only for the team, but ultimately we will open it up.

Day of Week for BIND 10 release

Please can we discuss (again) the day of the week on which BIND 10 is released.

BIND 10 DHCP is now on a two-week sprint cycle, but the sprint ends on a Wednesday. Is it possible to include the DHCP code into the BIND 10 release if the release is made on the Thursday of that week?

Larissa: I have been told not to release things on Friday. Monday is okay.

Jeremy: Monday is fine. What will happen is we'll have a couple days that are lost on the weekend. Also I don't want to be encouraged to work on it over the weekend (that's my personal preference).

Jeremy: I can finish it on Friday and just not announce it until Monday.

Larissa: Can I bring it up to business folks and get back next week? I understand how it is not important for a developmental release...

Stephen: Does it really make a difference if it comes out on Friday instead of Monday?

Larissa: Supposedly it does.

Shane: We could actually run the experiment. See if people download more on Monday or Friday...

Stephen: Since this is not production code, I don't see how it would matter.

Larissa: It's about eyeballs reading the e-mail or not.

Larissa: I'm not opposed to an experiment.

Jeremy: Thursday is not desirable because there could be last-minute commits that are regressions. Also there have been delays of 12 or 16 hours with every PGP signing.

Stephen: We did discuss this, but I though we'd decided to make it the Wednesday following the sprint finish? So we would have a week's delay?

Jeremy: The argument against that is that there was no phone call to discuss the release.

Shane: Also we didn't need the whole time.

Shane: So lets try Friday/Monday? for now, that still gives a little extra time after the final DHCP commits.

Shane: For next release?

Stephen: I was hoping to get something concrete in the next release.

Shane: So lets make the next release on the 14th. (2011-10-14)

Flaws in the reverse name trick for DNSSEC support

Should we solve this? If so, how?

Stephen: Some non-alphanumerics confuse the order. You should be able to define a different collating sequence, even in SQLite.

Stephen: \### ... can't we store that internally just as a byte, and the convert to text when we render the name?

Michal: We can't if the \### name is a dot '.'.

Shane: Since DNS is a binary protocol there is nothing you could use that will give the correct behavior.

Jinmei: Do we want to solve this?

Michal: I think we do. SQLite is presented as how to do stuff correctly... if we ignore problems we give a bad image.

Shane: I think we do want to solve it.

Stephen: An alternative one is internally when you have the structure holding the name, you tag on to the end of the structure something that locates the position of the '.' or the 3-digit codes that represent the dot.

Joao: DNS is actually not a binary protocol... the labels only use the 7 bits of the ASCII character set. Internally you could use the high-bit...

Stephen: What happens if you use \129?

Jelte: Most implementations support it but it is not required by the protocol.

Jinmei: The characters can be any 8-bit value, so in that sense it could be a binary protocol.

Joao: That's not true, which is why binary labels could not be made to work.

Jinmei: Isn't it only for the first byte of the label?

Joao: No, it's for every byte. The problem is that binary labels had 0 in them, and also the counts were non-ASCII.

Jinmei: In any case we have a simple example.

Jinmei: If we do want to solve it we just give up using the format of a domain-name-like thing. Then which one is the best is a question, but I don't think we can solve it on this call. My proposal is to bring everything to the dev list.

Shane: Sounds good to me.

Jeremy: Is there a ticket?

Jinmei: No ticket yet.

Jeremy: Do we have a unit test that shows the problem?

Jinmei: No that's just my theory.

Shane: A ticket would be good too.

Should data sources be captive or can they be "free"?

Or is it decided per backend basis?

Shane: My assumption is always that we would want both and that it would depend on the backend.

Jinmei: I have no opinion, and I would like to know what operators want.

Michal: I guess that if people tell us that they want the domain data in the database, that they want it in their database. If they put it in BIND 10 through some interface then they won't have to care about whether it is in their database.

Jinmei: If that's our understanding then we are doing the right thing. My concern is that if we go to the completely captive mode that we are over-engineering. If that's not the case then that's fine to me.

Making top page nicer/more user friendly

In discussions at the ISC all hands meeting, I realized the web page was not helpful. For example, it seems no one can reach the information on OS specific tips for building bind10 (I added a direct link from the top page to address this particular concern). there seem to be too many random links on the top page (and many are old or stale), and some are only useful for a very limited set of people (effectively hiding other information that would be helpful for a larger set of visitors). I guess we should consider clean up the page (at least the top page) so that it will be helpful for more people and help increase possible users.

Michal: I agree, because now the page is somehow a mix of development and we are not clear who is the audience of the page. Users or developers? We have a mix of both things there. We should have a big page like "this is for users", saying in nice words what BIND 10 is and why they want to download it and so on. And if you want to develop then here is a sub-page.

Shane's thoughts:

  • Link to "download"
  • Link to "report bug"
  • Link to resolver page
  • Warning about appropriate usage

Larissa: I think the biggest thing is that there is too much on the front page, so if we can restructure it to be more community-focused and put some of our administrivia on a secondary page that would be helpful.

Larissa: I do think that trying to point specific user groups to specific resources is a good idea, but I am not sure that the way we have it is right.

Shane: Is this something that we could get done before the release? The 14th?

Larissa: If you can find the proposal then we can send something to the team tomorrow or Thursday than we can get it done before the next release.

Shane: We can mock up a page and send that around.

Shane: If someone has strong feelings and/or wants to be involved then please let me know.

New Datasource API: missing bits

I just took a short look at #1207 (integrate ds factory class into auth), and there is another thing missing from the new datasource API, or rather, just above it; how do we handle multiple datasources? Do we use a MetaDataSource? that transparently handles multiple datasources as its own backends (similar to the original design), or do we put a collection of datasources straight into auth_srv? (currently it has this weird configparser set of classes that does all kinds of magic, I think we can make that a lot simpler btw).

Speaking of which, we also need some other things; the static ds with the new api, and we need to move the actual calls that makes inmemory read zones out of auth to the inmemory datasource (or add optional exposed methods to do such a thing)

Jinmei: I thought there was a discussion in a separate ticket? It was a side discussion, and we did not decide anything. I don't have a strong opinion. My not-so-strong opinion is that we will list the possible data sources and the authoritative server will try one-by-one. If someone prefers to make this more abstract so that it can also look like another kind of data source (like the current meta data source) then I am okay with that.

Jelte: So just having a set and going through is good enough.

Michal: I think we want some kind of meta data source because we will have more than just the authoritative server and this will be re-used. It will do exactly this.

Jinmei: Maybe Jelte can start a discussion on the dev list, and for the short term we can solve this in any way, maybe an ad-hoc way, for the authoritative server.

Last modified 7 years ago Last modified on Oct 5, 2011, 12:03:01 PM