Changes between Version 2 and Version 3 of WeeklyMinutes20101207


Ignore:
Timestamp:
Dec 7, 2010, 4:08:37 PM (7 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WeeklyMinutes20101207

    v2 v3  
    1 = MEETING NOT YET COMPLETED - MINUTES WILL PROBABLY BE NONSENSICAL =
    2 
    31= Roll Call =
    42
    53{{{
     4Jeremy
     5Michael
     6Aharen
     7Jelte
     8Larissa
     9Stephen
     10Shane
     11Scott Mann
     12Likun
     13Ocean
     14Jerry
     15Fujiwara
     16Michal
     17Jinmei
     18Keith
     19Kambe
    620}}}
    721
     
    1226Jeremy rolled out a release last week. We can talk about anything related here.
    1327
     28Jeremy: Nothing in particular except that this was a gap from mid-September to beginning of December. Had many many changes, but very few user noticeable changes. From a marketing perspective, we've done 7 releases but each is flagged as experimental. I'm wondering if we're losing our marketing possibilities by doing this. Maybe more people would have tried things if we branded parts of it as "ready to use".
     29
     30Larissa: Should we pick an upcoming release as "ready for early adopters"?
     31
     32Jeremy: Maybe not the whole release but probably parts of it.
     33
     34Jinmei: What do you mean by "flagged as experimental"?
     35
     36Jeremy: I don't know. The whole thing is marked as experimental software so it scares anyone away from even wanting to try it. We've only seen a few people in 7 months even trying it.
     37
     38Larissa: It would be interesting to see how many downloads we've seen, I can ask Dan (ISC Ops) for that. As we get to the end of the year we should push more adoption, and picking a release would be a good idea.
     39
     40Jeremy: If this was not BIND and was some other server I think they would have had 100s of people giving feedback. Even if it all died off it would have gotten a lot of publicity and people trying it. But I think that's a different discussion.
     41
     42Jinmei: Basically I agree. If experimental means "no so stable" I am afraid we cannot improve it until March 2011 for example. If it means "usable, interesting feature" then I completely agree with you.
     43
     44Larissa: I think when we have a release when all the changes are infrastructure related it won't get the interest of beta-tester type folks. There has to be a co-ordinated effort for what is exciting to them. I think we need to look at upcoming releases and flag a couple of them.
     45
     46----
     47
     48Jeremy: I did not add documentation on the stats component for the guide for this release. Part of the stats server is there, but I was not sure how much of it was there because there was a lot that was still to be committed. We'll catch up on that.
     49
     50Shane: We'll be seeing lots of commits about the stats stuff over the next few days.
     51
     52Shane: FYI I have been taking the release announcement and converting to a business-friendly version.
     53
    1454= SERVFAIL vs REFUSED: preference poll? =
    1555
     56Jinmei: Related to thread on bind10-dev list, also related to ticket for A-Team sprint. #415. What we should return if the authoritative server cannot find anything about a query name. The current implementation returns REFUSED, and according to the comment from Evan it seems to be for compatibility with BIND 9. Some implementations return SERVFAIL. There was a discussion about this on the namedroppers mailing list. There does not seem to be any consensus and it seems to be a matter of preference. In theory server failure is the more sensible response code in that case, but many others seemingly more like REFUSED. I wonder what our team think about it.
     57
     58Jelte: In effect it now returns REFUSED for compatibility with BIND 9. But the reason BIND 9 returns REFUSED is a side-effect from the way it works.
     59
     60Jinmei: That's right. In the case of BIND 9 it means the client cannot use the cache, because by default in an authoritative-only server the use of cache is prohibited. In the case of BIND 10 authoritative only we don't have a cache in the first place. For compatibility doing REFUSED is okay for me.
     61
     62Stephen: How important it compatibility?
     63
     64Jinmei: Personally it wouldn't matter much because there are other implementations returning a different response code.
     65
     66Shane: We have a slightly higher standard than non-BIND implementations.
     67
     68Michael: Also difference in perception... SERVFAIL may be interpreted as server failure. What you want is a code that says "I don't have that zone". There was some discussion about putting something in the OPT record about why it failed. There are like 20,000 reasons you can get SERVFAIL.
     69
     70Jelte: This may be moot, because in practice it will also almost never get that far because of ACLs.
     71
     72Shane: In the usual case for authoritative servers you won't normally hit an ACL right?
     73
     74Jelte: In BIND 9 you get REFUSED but that is because of an ACL. It is very hard to get BIND 9 to return the SERVFAIL, which it can, but you have to try really, really hard. If resolvers don't react differently on either it doesn't matter too much.
     75
     76Jelte: I like the idea of returning REFUSED unless there is an error.
     77
     78Shane: I also agree REFUSED makes more sense.
     79
     80Jinmei: Seems like rough consensus. If someone has a different opinion we can discuss on the mailing list. Otherwise I'll eventually change the code to return REFUSED.
     81
     82= R-Team status =
     83
     84And a quick discussion of what the R-Team is working on so that the A-Team knows!
     85
     86Stephen: The R-Team is working on using a forwarder, and also the first part of the cache. The forwarder bit has been sort of completed, although there is a certain amount of the ASIO to tidy up and the light. The changes there are pending one final review before we merge things back into the cache. For the recursive cache we've started work on the design for that. A couple of other things on the current sprint are setting things out for the logging framework. The Python logging has been done, but has been marked as experimental, the C++ logging has been done as stdout. Requirements have been done for that.
     87
     88Stephen: We have started to work on the backlog of bugs. Jeremy estimated something like 15-20 bugs coming in through month. So we will try to tackle 20 bugs split between the teams. So every sprint will tackle 5 bugs from the backlog and eventually take away the backlog. I've concentrated on the R-Team because that is where my work has been focused. Maybe Jinmei wants to say a few works about the A-Team?
     89
    1690= A-Team status =
    1791
    1892I'd like a quick discussion of what the A-Team is working on so that the R-Team knows.
    1993
    20 = R-Team status =
    21 
    22 And a quick discussion of what the R-Team is working on so that the A-Team knows!
     94Stephen: On the A-Team side the focus is on improving the performance. To that end the red/black tree structure from BIND 9 is being ported over. That is ongoing. There certainly seem to be not as many people on the A-Team as the R-Team. I'll include in this the statistics stuff that JPRS is working on.
     95
     96Jinmei: At this level I don't think there is anything to add. Maybe it will be useful that we are trying to provide some usable feature, rather than implementing the various different building blocks in a single sprint. So we re-arranged the sprint tasks so that we can return a very limited feature of authoritative server for the current sprint. Hopefully in the next sprint we'll have a version of the authoritative server for the next sprint. This is partially a response to Jeremy's concern that we don't have any interesting features.
     97
     98Shane: We had a discussion about breaking functionality. The idea is that refactoring may cause things to break.
     99
     100Stephen: Yes, and we'll have things working by the end of the 6-week period, but we've arranged tasks into 2-week sprints.
    23101
    24102= Off-list discussions =
     
    28106= how much of boost stuff we'd allow to use in public header files =
    29107
     108Jinmei: This is part of the discussion in the review of the red/black tree branch. It specifically about boost::noncopyable header file. My understanding is that we are trying to restrict the use of boost in public header files.
     109
     110Shane: That's correct.
     111
     112Jinmei: OTOH Boost has many nice features of course. We are intentionally using shared_ptr in header files. This is basically a trade-off issue between wider portability and richer functionality.
     113
     114Shane: Is boost:noncopyable part of the next standard?
     115
     116Jinmei: I don't know.
     117
     118Shane: If it is scheduled to become part of the standard then it is less scary.
     119
     120Jinmei: Even if it is adopted next year for example, the availability for various compilers varies.
     121
     122Michal: If we already include some of the Boost headers is there any advantage with not using the other? We need it so if we use the whole thing... actually noncopyable is only a base class with private copy constructor or something like that.
     123
     124Stephen: There is the general question as to how many other packages we can use. So for example I'm considering logging, and if our requirements are leaning towards log4cxx.
     125
     126Jelte: There is a difference between depending on something and having it in your own public API. Especially with Boost it has its own set of disadvantages.
     127
     128Stephen: In what way?
     129
     130Jelte: If you have it in your API, then you must provide those headers as well, or you cannot guarantee binary compatibility in the end. Back then we decided the features we were using are so unlikely to change that it is not a problem, but if you use more then that danger increases.
     131
     132Jinmei: For Boost for example, we use other features in our implementation files. So this is specifically about defining our external API.
     133
     134Shane: In the case of noncopyable it could be trivially implemented.
     135
     136Jinmei: True, but how much should we implement ourselves. We could implement it by adding 2 or 3 lines per C++ class, so it is not a lot of code.
     137
     138Michal: I tend to think that stuff like this is better using a comment in the documentation saying "please do not copy this because it does not work". Because you never can use a class without reading its documentation anyway.
     139
     140Michael: IDE's are getting smarter and smarter... people will find the function names! Can we just call the arguments "don't copy"?
     141
     142Jelte: You'd have to call the class that.
     143
     144Jinmei: This is closer to the idea of using noncopyable.
     145
     146Shane: Probably a good idea to document why it is not copyable.
     147
     148Jinmei: We use a trick like this to detect failure at compilation time.
     149
     150Shane: I think I'd prefer to use noncopyable instead of implementing it ourselves?
     151
     152Stephen: I think noncopyable is clearer, but we are going to how much of the Boost library we want to implement. You've got from boost.org a downloadable implementation you can compile on multiple platforms. I see your point about hiding details from client applications, but in practice if we do change anything in BIND then everything built on top of BIND will have to change significantly as well. What I'm saying is lets use Boost 1.44 and 1.45 and that's a fundamental building block and we can use it in any manner we want.
     153
     154Michal: I think that when we talk about noncopyable then noncopyable is probably much less probably to break than shared_ptr, and we use shared_ptr a lot.
     155
     156Jinmei: Yeah that's probably true. So it's about the specific case as well as about the general guideline of the amount of the reliance on Boost. Whether we want to minimize it unless we absolutely need it or whether we are allowed to use it as we see useful.
     157
     158Shane: Shall we just say "yes" to noncopyable and not worry about other Boost stuff? Unless people have specific stuff from Boost they want...
     159
     160Stephen: We could also say we will use TR1.
     161
     162Jinmei: Even if the interface is fixed the internal implementation may change and that may break binary compatibility.
     163
     164Stephen: Is that a problem? We can just rebuild everything from scratch.
     165
     166Jinmei: I'm not sure we're talking about the same thing. My concern is the case where we have a binary library somewhere and someone upgrades the Boost installed on the system and compiled their own program which is linked with an older version of Boost. Should we prohibit that and require rebuilding everything?
     167
     168Stephen: If I've got a library and I upgrade something based on that then I am going to get binary incapability.
     169
     170Jelte: Because it is header-only then you have a different set of compatibility problems.
     171
     172Michael: I would suggest just say "who cares?" and let the package maintainers figure it out. That's what they do. This is a problem that every single package manager has. That's why shared libraries are versioned. If you're exposing any part of boost at all you're exposing all of it, to a certain extent.
     173
     174Jinmei: That's one approach certainly, although I feel scared about that.
     175
     176Michael: Nobody is installing this in a package system now, so do what is expedient, and you can revisit it later. I don't think this is so different from requiring linking against an external library.
     177
    30178= BIND 10 meeting in January =
    31179
    32180Lets make sure we are all set up for travel.
    33181
     182Stephen: Someone needs to collect the dates when people are arriving to make sure the hotel is booked.
     183
     184Keith: The person who will do that is the new admin, Jeniffer.
     185
     186Larissa: I will see her this week so I'll speak to her about that.
     187
     188Keith: It will be useful to have a list of who is arriving, when they are arriving.
     189
     190Jeremy: What are the starting times and the end times?
     191
     192Shane: Maybe we can start at 11:00 on Monday, with talks with 1st time face-to-face meeting attendees on Monday morning.
     193
     194Jeremy: I always fly into San Jose because I always have rides. Should I use San Francisco?
     195
     196Larissa: San Jose is fine.
     197
     198Michael: Check prices.
     199
     200Shane: bind10-team is best place to discuss face to face meeting details
     201
    34202= Git migration status =
    35  
    36 = Scrum feedback/updates =
    37 
    38 If we have time, we can talk about how we think the Agile stuff is going.
    39 
    40 Jinmei suggests: how to handle non sprint tasks (I'm specifically referring to reviewing the statistics stuff)
    41 
    42 = A.O.B. =
    43 
     203
     204Jeremy: Plug in for Trac called the Git plugin. It is experimental, has a lot of reported bugs. Developer has limited time.
     205
     206Jeremy: Converted all data from Subversion to Git like 5 times before I realized that the version was losing information on conversion. Installing new version of Git on the box, because Debian doesn't have the new version.
     207
     208Jeremy: Editing the existing content (commit logs, Wiki pages, and so on) because they reference Subversion differences. Pointed to multiple repository of Trac - Subversion for historical and Git for future stuff.
     209
     210Shane: Possibly safer than doing our own markup.
     211
     212Michal: Do we use integration of Subversion into Trac? It highlights ticket numbers and so on. I look in my repository and look there.
     213
     214Shane: I do occasionally use it, but I don't do much development.
     215
     216Jelte: Just pointing to revision numbers is what I use.
     217
     218Michal: If what we gain to migrating before this is solved... would it be more or less by what we lose with Trac integration? Are we trying to solve a real problem?
     219
     220Jeremy: I think some of us do use that Trac feature so we can quickly point to a revision in a Wiki message or a commit message. I've seen others use it.
     221
     222Shane: Maybe we should ask the list?
     223
     224Jeremy: Is the alternative to use gitweb?
     225
     226Michal: No, not integrating at all. From my point of view having Subversion with integration is less good than Git without integration.
     227
     228Stephen: I don't think I would miss the integration. I do make references but that is just to note the revision, rather than to provide a link to it.
     229
     230Jinmei: Are we talking about Trac integration in general? [ Shane: We're talking about Trac/Subversion integration in general. ] I personally find some of the features very useful, but as long as I can find an alternative way I'm happy with that. For example as long as I can browse the difference between two arbitrary revisions via a web browser it should be okay whether or not it is Trac.
     231
     232Likun: I agree. At least there should be an easy way to provide the difference.
     233
     234Shane: Maybe we should see if there is a way to disable integration to not confuse people.
     235
     236Jeremy: So on the new install, disabling that we will lose context on old tickets.
     237
     238Michal: They probably could be changed to the SHA1 hash from Git if it really matters.
     239
     240[ Shane ends discussion due to time ]
     241
     242----
     243
     244Jeremy: More work to migrate SQLite to Postgres. There is a tool. The only goal is to give us better performance, but it might not help us at all. Other people have noted even with other database back ends.
     245
     246Jeremy: The bind10 server box itself is getting a huge mix of software installed in all different places. One reason is Debian is out of date, but also installing different versions of Trac. We're using the same box for a lot of different things.
     247
     248Jeremy: Finally, I'll have a very short guide to explain common Git uses for BIND 10, with some comparisons with Subversion commands.
     249
     250Jeremy: We need to pick a day ... a deadline. Do we want to switch regardless of Trac? January 3?
     251
     252Shane: I think we do want to do that.
     253
     254Jeremy: Okay we'll start using Git the first week of January.
     255
     256Shane: Can you send a mail to bind10-dev so people not on this call know?
     257
     258[ Out of time... meeting over! ]