wiki:SprintPlanning20110419

BIND 10 Sprint Planning Meeting

2011-04-19 14:30 UTC

Present

jreed
Stephen
vorner
Shane
Likun
Ocean
Jerry
Jenny
Jelte
Fujiwara
Jinmei
Kambe
Aharen
Chao

Review of past Sprint - organizational

  • What were the goals for the Sprint?
  • Did we achieve the goals?
  • Was task assignment and categorization useful?

http://bind10.isc.org/query?status=closed&milestone=Sprint-20110419&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=time&col=estimatedhours&order=id

Stephen: Were there definite goals?

Shane: We are trying to work towards TSIG at the next release

Stephen: So no definite goals for this sprint?

Shane: No.

Jinmei: When is the next release?

Stephen: In 4 weeks' time.

Stephen: TSIG out at next release. Can we put definite goals of what we want to achieve in the next 2 weeks?

Shane: tickets #810 to #816, plus #781 and #782

Jelte: #781 nearing completion

Jinmei: implicit dependency on refactoring

Jelte: TSIG would introduce 2-way dependency between TSIG and libdns unless we do #749; but it should be ready for merge

vorner: You mentioned #810... one small thing... uncomfortable to use configuration from a different module, no possibility to have function call when we update. Not a problem for TSIG but it will be for logging. So maybe there will need to be another ticket for reconfiguration.

Jelte: there is an older ticket for that... (ticket #252)

Stephen: Looking through tasks that have not been completed on the current sprint. Did critical and major. With Scrum, on each sprint you are aiming to complete something.

Jinmei: Maybe we can complete the basic TSIG signing, and then we will be able to send a query with TSIG signing.

vorner: Is verifying more important?

Jinmei: Of course, but we can show that if the server is configured that we can send a query and get a response.

Stephen: Let's finish the past sprint first! So, no definite goals, we can't say if we achieved them. We did assign tasks into priority. Were those priorities useful? Were they useful when you chose the task you were going to do?

Jeremy: I see some are defined as blocker. I'm wondering if we really do have a blocker issue - if we really do have a blocker issue if that will be ignored. Or maybe I don't know what blocker means.

Jelte: If you mean blocking other tickets or blocking a release.

vorner: I believe we just use them as what should be done first and what should be done next, and the description was not accurate here.

Shane: My goal was to be able to look at the list and see what was more important.

Jelte: Maybe better to name them low to high.

vorner: The colors are nice - everybody knows what red means. We don't really need anything unless it confuses people.

Jelte: 'blocker' does confuse - it has another meaning.

Shane: I meant the sprint would be successful if our 'blocker' tasks were done.

Likun: currently we put categories on task according to component. Maybe when we support TSIG we plan on creating separate tickets. From the task backlog we can't see the relationship between the several tasks related to TSIG. I just attended some scrum training and one user story has several task backlog.

Shane: That does make sense, but we're out of fields. :)

Stephen: Broadly speaking we have "component" which is a high-level structural field. Do we use "component" now?

Shane: We don't currently use it for decoration, but I was going to propose we have 3 components "core", "dns", and "dhcp".

Jeremy: Sometimes it adds more information.

Stephen: Are there user-defined fields in Trac? [yes] Would it be useful to do this? Create one for "dhcp"/"dns", and then create one which is "feature", where we can group tasks related to a given feature.

Shane: I think it makes sense.

Jeremy: Is "feature" something that would be changing all the time?

Stephen: No, it's to address Likun's point.

Jeremy: I'm not sure how we can do that in Trac, other than manually editing a config file.

Shane: Can we make it a text field?

Jeremy: I don't know... maybe.

Stephen: I think maybe a text field is all we need. When we create the tasks after a planning session, we would assign this "feature".

Jeremy: It would also be useful to have a field for priority that wasn't tied to a sprint but was assigned to a release. For example bindctl might be broken and the server fine, and we might ignore it because it's hidden. We need some way to mark it as a blocker issue. This is what I did on the last release. I had like 6 or 7 critical/blocker tickets. We had known failures.

vorner: Well, we can because we have tickets inside the sprint and tickets outside. We can adjust the priority as it moves inside the sprint. But it can be confusing.

  • Priority: level within a sprint
  • Severity: applies to defects more than anything else

Stephen: Jeremy can you look and make proposal to bind10-dev list?


Jeremy: In the past sprints seemed like they had maybe 15 to 20, so it made it fine-tuned. Now it looks like there are 45 or more tasks. After the next 2 weeks it might grow slightly to 50. I did not know if that is a concern.

Stephen: It is a bit of concern. It is something to talk about when we come to planning for the forthcoming sprint.

vorner: If we chose from the red ones first, then actually the selection of tasks is limited to what we need done. The blue tasks are like, well, if we are really really fast and run out of work. They weren't meant to be completed in the sprint.

Shane: I wanted to make sure if we finished all critical tasks there would be work to do. This is probably not good for scrum!

Stephen: Also useful to place some very small items.

Stephen: If we have a lot of tasks and they are related to a bunch of features we could spread our work around and not complete any features.

Review of past Sprint - technical

  • Any technical problems that may have an impact on issues such as BIND 10 design, implementation, build procedures, testing etc?

Stephen: one that came up this morning was ASIO

Jelte: Use of ASIO in a recent merge needed a specific header to be included for Sunstudio. I don't know if we could have prevented it. Michal mentioned whether we had looked at a newer version of ASIO which has finished this. I created a new task, ready for review, to upgrade the version of ASIO that we use. I'm not sure how this relates to the sprint planning...

Stephen: technical issue that came up in the sprint, new version requires suppression of a warning...

Jelte: ...and allows another one to be removed! We don't need to include <unistd.h> before <asio>.

Jinmei: I've seen big changes that affected the entire build tree this sprint. That sometimes broke builds for example. I don't know if that's a concern or not.

Stephen: What change?

Jinmei: Changing a library to a separate place.

Stephen: Restructuring the build tree?

Jinmei: Sort of.

Stephen: More of a concern when it came to merging?

Jinmei: I don't know if it's a concern. But it's an observation of mine.

Jelte: If #749 gets merged, we will have more of that. It will break a lot of branches when they get merged, if they added or changed any includes or any namespace things that relate to the changes in #749, merging will be a bit harder.

Jinmei: In that sense, one possible related point is why we chose this task despite its great effect and the fact that it categorized as minor. It may be good to record that so we can make a better plan in the future. Was this found out to be urgent?

Stephen: I don't think it was urgent. But we do it now or we create more duplicate code. This particular one is putting utilities in a particular place.

Stephen: Any suggestions how to avoid in the future?

Jeremy: Maybe a head's up e-mail

Likun: We should think about the workload from branches when we merge other tickets. Maybe this ticket is very minor but it makes merging work very bit.

Stephen: I found it was easier to take changes from a new branch from master.

Jelte: I did that and it caused problems for someone else this sprint. Any branch that was created from that branch was also invalid.

Stephen: Branch from branch is relatively rare.

Jelte: There are use cases for that.

Jinmei: Another idea is to run autobuild from some branch, if we expect it will cause breakage.

Stephen: Run a branch on the build farm? We discussed...

Jeremy: The conclusion is "yes we will do that".

Stephen: How will we do that?

Jeremy: Hasn't been designed yet. I have not had time to do it. It could be as simple as a web page - put branch name in and click "submit".

Stephen: Summary - this is a problem. Currently the only thing we can do is if you have a ticket that will move things around and change structure that you send an e-mail to bind10-dev warning people that this is going to happen.

Sprint Planning

  • What are the goals for the next sprint?
  • What tasks do we carry forwards?
  • What tasks do we add?
    • Tasks requested by Jinmei for inclusion into sprint
    • Tasks assigned but not in any sprint
    • Bug fix tasks to be added to this sprint

Stephen: resume our discussion - send TSIG and get response?

Jinmei: I meant updating the experimental "host" implementation

Jelte: the client side... so we can at least check that we can sign and/or verify

vorner: Do we want Python bindings for the next sprint?

Shane: I think it makes sense, because otherwise we have to do Python bindings and xfrin/xfrout changes

Jinmei: I'm not so sure if we will have time.

Jelte: It does make sense to have Python bindings,but it makes more sense to get the API first.

Jinmei: I don't think we need a direct Python wrapper for the crypt API

Jelte: I agree! We need to know how we implement it before we have the Python wrappers.

Stephen: I would like to propose we have at least 6 modules using the logging interface. I just chose 6 as something we can measure progress against.

Goals

  • TSIG sign/verify
  • TSIG-enabled "host" command
  • Python TSIG bindings
  • Logging interface for 6 modules

Jelte: are modules libraries or programs?

Stephen: logging as defined as tasks.

Jinmei: To be sure, which tickets will be solved regarding TSIG.

Stephen: That's what we are going to do now - decide which tasks get put into the sprint.

Stephen: We completed 79 estimate points in this sprint. This compares favoribly with previous sprints. Totals in split teams were 63, 67, and 80. Anywhere between 60 and 80 estimate poitns seems to be a reasonable goal per sprint.

Tasks Carry Forward

#414 is large - should be broken into smaller tasks #765 is going to be relatively small #547 looks large... estimate of 40 is going to distort the numbers

#812 TSIG #811 TSIG #684 bug

Accepted + assigned + review is 42 points

Looking at 35 to 40 points for new tasks.

New Tasks

#813 TSIG #814 Python TSIG bindings

#813 depends on #812 because verifying and signing are tightly coupled

Jinmei: it might help to decouple Python bindings for verifying and signing

NEW TASK - TSIG-enabled "host" command

#735 logging #743 logging #744 logging #745 logging

http://bind10.isc.org/query?id=838&or&id=846&or&id=847&or&id=851&or&id=542&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=time&order=id

Stephen: Where should new tasks go?

Jinmei: I don't mind, but I think we need some milestone or something.

Stephen: I haven't created one, because we have a bunch of tasks not associated with any milestone. Things go into the general task pool and tend to get forgotten about.

Shane: Maybe we should treat bugs/defects separately, and those do not need to go on any milestone?

Stephen: I have a link of open bugs that don't go on any sprint.

http://bind10.isc.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&owner=&type=defect&milestone=&or&status=accepted&status=assigned&status=new&status=reopened&status=reviewing&owner=UnAssigned&type=defect&milestone=&max=999&col=id&col=summary&col=type&col=owner&col=priority&col=component&col=time&col=estimatedhours&order=id

Stephen: Are we just letting the bugs build up? Should we have a sprint where we only tackle bugs?

Shane: I don't think we need to answer it for this sprint...

Stephen: This sprint or the next sprint... but in the following 6 weeks do we want to reduce the number of features we implement in that 6-week period.

Jinmei: I think we should include bug fixes in every sprint, whether or not we have a dedicated bug fixing.

Stephen: We want "filler" tasks. I propose that we just take the 5 tasks that Jinmei have identified and add those to the sprint.

Jeremy: Also #833. There are 3 in review state, but they aren't listed yet. #374, and #855.

Jinmei: #374 need to revisit, when we do dynamic update thing. In my opinion it's not an urgent thing and we will not forget it.

Stephen: Add these to task list and maybe Jeremy can go through these and anything else in any state other than "it has been created" and bring to our attention, as input to next sprint planning session.

Jinmei: statistics tickets seem pretty big, so maybe we should consider how to break these tasks

Stephen: something we can do on the mailing list over the next 2 weeks

Last modified 7 years ago Last modified on Apr 19, 2011, 6:39:23 PM