wiki:SprintPlanning20110628

BIND10 Sprint Planning Meeting - 28 June 2011

Present

Shane
Stephen
Aharen
Likun
Ocean
Jenny
Jeremy
Larissa
Michal
Jelte
Kambe
Fujiwara
Jinmei

Review of past Sprint - organisational

  • Selection of tasks for sprint Do we "slack off" as we get to the end of a sprint?
  • Other comments

Jeremy: Different tickets that depend on each other. From an outside point of view I could not tell where we were at. Too many places to hunt down. Maybe because I am not on the call, but I could not tell how status was communicated - not in e-mail or tickets.

Michal: We don't talk much about this on phone calls. I usually have a look at e-mails and try to keep an idea of how things are going and which tasks are closed and so on. Mostly because I try to remember the interdependencies of the tickets.

Shane: There are Trac plugins which document inter-ticket dependencies. Has not been a high priority.

Stephen: Two things... interdependencies and progress. We are more aware of dependencies, but we do not explicitly plan out. Because there is a decentralized aspect, everybody just taking whatever task they like, we don't know the size of particular features. There was nobody saying "where are we with ACLs, do we need to create tasks?".

We did talk about that a little while ago. There was the idea of a feature lead, but we did not appoint anyone for the ACLs.

Michal: I tried to look at them and see if they are on the right track. As you said nobody appointed anybody, but I tried to have an oversight. Maybe I am too invisible and silent about it. I do think the ACLs are moving to the direction of being finished.

Stephen: We think they are moving in the right direction. We think they are finished because all the tickets related to ACLs are being done. Do we know that?

Michal: There is one task created because of how the tickets did not connect together. So we have one that needs to be done for it to be finished. We have nothing for the Python part. So we are mostly finished in terms of work but not features.

Jeremy: My concern was implementation for the end-user interface, that customers may use over the next 6 to 9 weeks. In hindsight maybe that should have been in a sprint.

Michal: Yeah, there is no user documentation right now.

Stephen: Do we think that this is a problem? Lack of oversight for the progress of a feature?

Jelte: Well, for Jeremy it is! In his function as a release engineer. So I would say "yes".

Jeremy: I also want to mention... since there were so many tickets, I was confused as to which part was the user feature. Looking from outside it's confusing to me, since I wasn't doing the development.

Jinmei: What kind of oversight are we talking about?

Stephen: Somebody who's job it is to keep an eye on the feature and all the tasks. See if there are any missing tasks. So, for example, documentation.

Jinmei: The oversight thing sounds like a manager for a specific task or something, or manager for a specific feature, which seems to be not an agile way. If we feel the need for it maybe we are doing something wrong.

Stephen: We have compromised agile anyway... it is designed for small teams working closely together in one room. We are separated around the planet.

Jinmei: If we do some specific thing as a compromise that is fine. But if we do not understand what we are doing, maybe we are just getting lost.

Jelte: Keeping an eye whether the task becomes the user visible feature is the role of the scrum master, right?

Stephen: The scrum master facilitates scrum.

Michal: I have seen other Trac/Bugzilla sites do... meta-tickets. All this discussion is done on the meta-ticket. Would it make sense?

Shane: Maybe we need to look at the problem (missing stuff) rather than solutions?

Stephen: On our mid-sprint call, maybe we need to put sprint progress on the agenda?

Larissa: I think that would help. I am also not opposed to the meta-ticket that Michal proposed.

Stephen: Okay lets try that.


Jeremy: Some of the new tickets created may have a 1-sentence description. I have a feeling that they are too vague. A 5-minute conversation is condensed into 1-sentence. On last sprint, we talked about XML output. That is just an example, it has happened other time.

Larissa: It is common in Scrum to put "conditions of completeness" into the ticket.

Stephen: I think that would impact us as we generate the tickets then. We would need to put more as what is involved. But what we did at Prague was go through as many topics and generate as many tickets as we could before everyone fell asleep.

Larissa: Maybe this is something that I need to work on... I'm not sure how to solve this.

Shane: Perhaps writing tickets as user stories would help.

Larissa: Not sure if we want to do it before the next face to face?

Stephen: I think this would require a lot more discipline. So, for example, modify the text in the NSAS messages becoming "as a user I would like the NSAS messages to more completely describe the problem". ;)

Larissa: User stories may be more useful for requirements.


Jinmei: There are some ACL-related tickets that were not reviewed for 3 or 4 days while we were working on logging. So it seems to me, especially at the end of the final sprint for the release cycle, that there is some kind of priority inversion.

Jinmei: As long as this is a moderate problem perhaps we can accept that for now.

Stephen: I can try to ask people about that.

Shane: We have daily calls for this.

Michal: I did raise that issue (on Jabber)...

Stephen: And I was ashamed enough that I reviewed them right away!

Jelte: And the list got a bit bigger towards the end of the week, but the reason for that was that a lot of stuff got finished!

Review of past Sprint - technical

The goals of the sprint were:

  • Finish Logging
  • Implement ACLs on the Resolver

Finish Logging

Stephen: Still some modules left to add messages too. I don't think it holds us back from releasing the current version. It will just take another sprint to complete the conversion.

Jeremy: The new logging introduced a serious regression in performance.

Stephen: With debugging enabled? All that should happen is if logging is not enabled then the logging should be bypassed. So unless that is hampering performance...

Jeremy: I think I created a ticket. If not, then I will do that this afternoon.

Stephen: To be looked at as some matter of urgency.

Stephen: If debugging is enabled then it makes sense. If not, then the basic check is very, very slow.

Implement ACLs on the Resolver

Michal: Can check IP address and either drop/reject/accept. Full ACL syntax does not work there yet. No abbreviated forms, no logic operators, nothing like this.

Shane: TSIG support?

Michal: No.

Jinmei: Maybe we did not have common understanding of what "ACL for the resolver" was. I thought our original requirement was to have a very simple form of ACL that has only rules for source address of incoming queries. In that sense we have completed our goals. True that we did not have TSIG, but I thought that was out of scope for the revised version of the goal.

Sprint Planning

(from Shane's email of https://lists.isc.org/pipermail/bind10-dev/2011-June/002410.html):

Shane: We have additional work from the release. This would only give us 2 sprints for the next release. What to do?

Stephen: We also need to handle the bug backlog. We could do the next sprint as tidy-up. Finish logging, finish ACL work, fill it out with bug fixes.

Larissa: We have a big plan, but if we convey the message then I don't think it is a problem.

Shane: And above all we have to be realistic.

Jinmei: I think ACL needs more work, absolutely. Limiting to IP address for resolver is relatively minor in terms of feature. What we wanted to have is TSIG-based for xfrout, which we don't have. Without it we cannot say we completed the ACL work. So I believe it should be done sooner. I am not so sure about the logging - it can be improved gradually. In my opinion it does not have to be done in a single sprint. I thought this could be something like improvement for RR type support in libdns++.

Shane: You mean a large set of smallish tasks?

Jinmei: Yeah.

Michal: The logging conversion are not that small. But they are small and can be done any time.

Jelte: I think there is one big logging task, which might need to be split up: the entire Python library. Also these logging take more time than I would have thought.

Stephen: In part because you are writing the documentation as well.


Stephen: Design tasks?

Michal: Have we decided about the msgq?

Shane: No.

Larissa: That may be appropriate for here.

Shane: Also... writing data sources. Is there overlap?

Michal: Hard to design if the code does not exist.

Jinmei: My refactoring proposal includes that. I don't think there is more design work, beyond whether we go with this or we need something else.

Shane: Hard deadline of next sprint for decision. Was posted 3 weeks ago.

https://lists.isc.org/pipermail/bind10-dev/2011-June/002314.html

Shane: Also how we implement multiple core support.

Michal: I think we need more discussion rather than design.

Stephen: I think we need the proposal written down, so we can comment on it.

Michal: Shall I dig up the discussion?

We're going to be starting work on the next release next week. Most of the work on this will by necessity be groundwork for the *following* release, I think. It doesn't seem likely we can add DDNS/IXFR in a 6-week period, if we're going to do it right.

Here's what's in Wiki now:

  • DDNS
    • New model for writing to data sources
  • IXFR-out
    • New model for writing to data sources
  • IXFR-in
    • New model for writing to data sources
  • High-performance data source
    • Refactor of data sources
    • Profiling of refactored data sources
    • Performance improvements to existing data source done
    • Update NSD-inspired prototype to match refactored code
  • msgq replacement
  • All RRTYPE codes implemented
  • Socket creator completed
  • b10-auth use multiple cores
  • Equivalent of "rndc reload" and other such commands for in-memory data source(s)

Goals for the new sprint

Stephen: Summary. For the short term:

  • Finish logging
  • Finish ACLs
  • Bugfixing
  • Design

What tasks do we carry forwards?

All of them.

What tasks do we add?

Tidying up Next-Sprint-Proposed

Jeremy: I had an e-mail with like 18 issues about logging. I think that would turn into 5 or more tickets.

Stephen: I'll turn those into tickets to be added to the sprint.

#693 Solved (possibly)
#712
#714
#768
#910
#926 (only if found to be needed later on)
#981
#983
#988 Solved (possibly)
#994
#1006 Solved (possibly)
#1009 Done (possibly)
#1016
#1024
#1025
#1029
#1053
#1069

We also need tasks for xfrin/xfrout ACL checks.

#772

Jinmei: we should sort tasks by priority

+ticket about logging that affected Jeremy & Jinmei (I don't know what this means)

Any Other Business

Jeremy: Branching for the release in 2 days, then preparing for this next week.

Last modified 6 years ago Last modified on Jun 29, 2011, 11:01:01 AM