BIND 10 Sprint Planning Meeting

2011-05-31 14:30 UTC



Review of past Sprint - organisational

We had some trouble with task interdependencies in the last sprint - how were they in this one?

Jinmei: Not the same problems.

Michal: I always had something to choose from.

Jinmei: Because it is the beginning of the release cycle. We have some housekeeping or things like that. This does not necessarily mean we are improving something. Just a matter of timing.

Shane: ACL stuff involves a few bottlenecks which we will see later on.

Michal: I think it is not about timing but about the kind of tasks we have. Not much we can do about it.

Jinmei: That's right. Good to keep in our mind about the point of time in release cycle when we will have this problem. Maybe we can try to deal with it a little better than before.

Stephen: If we get to the point where we have a sequence of dependences, maybe we should broaden the front of work. So rather than finish one feature, we should start work on multiple features and realize that we won't get that feature in the next release.

Did the task estimating work?

Michal: I think the estimating of number of tasks was pretty accurate. We have 3 unassigned tasks left, and that's it. Despite the fact that our numbers are not accurate, we got the right number in the sprint. Or maybe we are just lucky.

Jelte: We do have a few unfinished tasks...

Michal: But then we would have to stop all work at the end of sprint.

Stephen: When I've been putting up the sprint results, there is an implicit assumption that the amount of work from previous is the same as the amount of work for the next sprint. We could add in more small bug fixes. That would slow features.

Michal: And we would run out of small bug fixes. Because the small ones would be easy to do, and we could not do the large ones...

Stephen: The only way I see around it is to do estimates for the following sprint, but that assumes we know which tasks we will have in the next sprint.

Michal: Doing extra estimating.

Stephen: We had a head-start after Prague.

Jelte: Can "proposed next sprint" milestone help in this?

Jelte: Should have list as complete as possible a day before, and then estimate everything on the proposed list, and then we pick from those.

Shane: Was thinking this was just sort of for personal preferences. Not intended for all tickets for next sprint. We could do that though...

Stephen: But we don't know what we will do in the next sprint. But we could estimate everything on the proposed milestone, even if we don't add it.

Jelte: For feature things not on the list, well, at least we have more estimates than we do now!

Stephen: Proposal: Once a week we try doing e-mail estimating. Mostly come from the proposed-next-sprint milestone, but also in coordination with Shane and Larissa. Gradually we get estimates for all tasks in our lists. Jelte: Sounds like a plan.

Larissa: Good idea. How long in advance? (Right now Shane and Larissa meet on Fridays.)

Stephen: Was thinking weekly.

Jinmei: I think it is worth trying.

Jinmei: How many developers answer your queries about estimation for these several weeks?

Stephen: Normally 3 or 4. I include the names of the people who have replied.

Jinmei: As a general concern it may not be good, especially if we more heavily rely on this kind of estimation. It is only a relatively small subset of developers.

Stephen: At the moment it's the only data we have got.

Review of past Sprint - technical

The goals of the sprint were:

  • Finish TSIG
  • Define ACLs
  • Logging and Logging Configuration
  • Bug fixes

(These can be found here.)


Missing #816 (XFROUT TSIG), currently being worked on. (Maybe finished tomorrow.)

Jinmei: Reason this work was not done? Taken early in the sprint...

Likun: Other CNNIC work, so Jerry could not focus on this ticket full-time.


Michal: Quite concrete proposal. Got responses from 3 people. Nobody said "this is complete crap". I think it might work. I created some tickets that we can just take, split into tasks with dependencies.

Stephen: I read as well and it seems to make sense.

Jeremy: I think we need to schedule a phone call just to talk about it. I was thinking something more advanced than BIND 9 - ACLs that could return REFUSED or SERVFAIL, or other advanced opportunities.

Michal: Is it the ACLs or how they are used then? I see ACL as something that says "yes" or "no". What you do with it is one level up.

Jeremy: I agree with that. The other thing is, how it is configured/used is another level.

Stephen: I think if we're going to have a phone call about it then we need it soon.

Jeremy: Did we pay a consultant to design part of this already?

Shane: No.

Stephen: I think the idea of an ACL library as a separate product is a good one. For example John Dickenson is working on NSCP, so anything that can work on that would be useful. (He is working on a prototype.)

Jinmei: I think having a separate discussion time is a good idea. It is something that the operators are more concerned about that developers. Especially JPRS and CNNIC. But I don't think we should stop the scheduling due to that.

Stephen: That is what I was going to say... if we send out for opinions we could stall on ACLs.

Michal: It might be a good idea, but I don't know what kind of development we can do before it.

Stephen: So if we have a call we should do it very soon, like this time tomorrow.

Michal: This might be a problem for me. I have an exam 4 hours before then... it might be over before that...

Jinmei: I think we can do any kind of development, as long as we have a chance to get broader opinions in this sprint. In the worst case we should drop everything we do in the next 2 weeks.

Stephen: Is this call a good idea?

Michal: I think it is. If it is bad people won't like it.

Shane: Do we want to invite people outside of the BIND 10 team then?

Stephen: Certainly Evan would have something valuable to contribute. The wider you consult the longer it is going to take, and the more opinions you are going to get.

Jinmei: For ISC internal operators we can just ask directly. And some of us can join the call on behalf of them.

Michal: Do we need for it to be a call? People probably want to read the proposal.

Jinmei: One good thing about having a specific time is that we have a deadline, so it will be a stronger motivation to read the proposal more carefully and think about what to say about it. But I do not insist on having a call.

Stephen: For just ISC people, asking for feedback from close-of-business Friday (17:30 PDT).

Michal: Sounds good to me. Would it work for you Jeremy?

Jeremy: That should be fine. I am unsure if this is internal configuration or the outside interface for configuring it.

Michal: I tried to describe the external interface, but there are some details about implementation. Maybe whoever writes an e-mail should tell them they are free to ignore those implementation details.

Stephen: Who is going to write it, and who is going to be sent to.

Shane: I can send it, I am not sure to whom though.

Stephen: Jeremy can identify concerns, and Shane can get it off by tomorrow morning.

Shane: So we'll proceed as if we have no feedback, and adjust based on feedback depending on what we get.

Logging/logging configuration

Stephen: log4cplus just merged, causing builds to fail (no fundamental problems), implementation of output to different logging targets (one ticket in review, another in proposed for next sprint, ticket for configuring logging being worked on)

Bug fixes

Shane: 8 done!

Sprint Planning

The goals for the next sprint were outlined in an email from Shane to bind10-dev.

"With our big goals for the next release being ACLs and completed logging, I would like to suggest that we need to have a lot more work on the ACLs in the next sprint.

In order to complete the ACL work for the release, I think we should have the current ACL tickets complete (the syntax work that Michal has started), as well as tickets #768, #769, and #770 - the configuration, and C++/Python libraries.

In order to complete the logging work for the release, we need a Python API. This is a blocking task for converting all of the Python programs."

What tasks do we carry forwards?

Everything except for #833 (below).

What tasks do we move to the general pool?

#833 [b10-resolver] Nameservers unreachable but really are

What tasks do we add?

Shane: Added "reviewing" tasks since the work has already been done.


Tasks associated with ACLs
Everything (except syntax) depends on abstract base class interface. This is really simple and small.


Check IP address, and so on, can be parallelized.


IP, TSIG, probably others, #769 has a list of these (some tickets need to be created). Then long dependencies

#978 simplified loader
#979 logic base class
#980 loader modification (take into account both #978 and #979)

Stephen: Maybe a design page on the Wiki?

Michal: I might create that... it probably would not be today.

Stephen: Something tomorrow would help people when they take an ACL ticket, so all the tickets can integrate it.

Michal: Tomorrow or the day after for sure.

Jinmei: Realistically what do we want to do with ACL... the first phase will be to use it with TSIG for transfer and/or restricting the query for the resolver. I would like to know the set of tasks that is specifically related to these goals.

Michal: #977, ACLs for TSIG/IP address (no ticket left), Named ACL objects, and Python wrappers, and #768 for configuration checking. The others are extending the ability the ACLs can do.

Jinmei: So I don't understand the entire picture. But if we can concentrate on some subset of the tasks for feature-level goals so we can provide something visible and useable in production-level environment for the next release.

Michal: I will send an e-mail to Stephen about which the most needed ones are no that pathway.

Stephen: A brief e-mail would be useful.

Tasks associated with logging

#976 syslog

Jinmei: There are tickets from TSIG.

Shane: I'm nervous about making the ACL for the release.

Stephen: Lets review next week, and see if we can add it?

Jelte: I did one... #985.

Shane: Also #681 and #955 and #639.

Any Other Business

Jeremy: I think we need a task to go through all the logging we have, rather than as a module. Just one big task.

Stephen: Can I suggest we put it on the sprint after?

Jeremy: One ticket to collect all noticed issues.

Stephen: I think it's a good idea.

Shane: #756 Python logging API

Stephen: We need to update our modules to use this...

Shane: Yes, but not in this sprint.

Jeremy: Anybody have holiday time?

Jeremy: I will be unavailable for 1 week (next week).

Shane: Jelte & Shane off Thursday (and Shane Friday).

Last modified 7 years ago Last modified on May 31, 2011, 5:00:15 PM