Note, excuse the layout, I have to run now, will fix tomorrow.

Sprint Planning Meeting 2011-09-27 Attendees ---

Stephen Shane Aharen Jelte Jeremy Stephen Michal Dima Jinmei Kambe Fujiwara

Review of Past Sprint - Organisational ---

Stephen: ISC all hands took people out for 2 weeks rather than the 1 of last year. This was in part because it straddled the weekend, so people were travelling on working days. Jinmei: Was this a 3-week sprint? Jelte: Yes. Should have been able to do work for 1 week at least. Jelte: We closed 7 tickets. Quite a few in review. List of tickets was large for this sprint. Shane: Looks like 21 points (although some are marked as 0). Stephen: Unwilling to take tickets that will extend when I am away. Jelte: 2 of tickets that I did were quite a bit larger than I originally thought. Michal: Yes, the NSEC one was large as well. Jinmei: Some tickets are almost ready for merge, so it is not as bad as it may look. Thinking about many people are travelling, realistically the overhead is larger than 1 week off. Jelte: I also sense that we are getting worse in estimating. I don't have details, but it feels that way to me. Jinmei: Estimation tends to be wrong, or that we are not making them? Jelte: Usually people are making estimates, but I feel that we are underestimating more. Or maybe underspecifying. This is just a feeling. Stephen: I wonder if it is because tasks are more complicated than we think, so definition comes from someone who has thought about the problem, with brief descriptions that hide a lot of detail. I wonder if we should not concentrate more on design. We are very keen on coding. We have tried to get design in the sprint before the coding, but it seems like designs are an obstacle in the way of doing the coding. Michal: I don't know if that is the problem in this case. The NSEC branch took me 24.5 hours of work already - more than a working week for me - it was not that there was a need for designing. There were lots of corner cases, and lots of tests. It took some time. Stephen: In that case maybe the problem is not the design but rather the specification. If we had outlined it, and thought through some user cases, we might have had a better estimate. Michal: I don't know. It looked simple when I looked at it. Even if we had the details, it would still look like a simple task. Stephen: NSEC has been around for some while, I wonder if we had actually taken time to do research and spec'ed it out better if we would have a better estimate. For example some of the things we've been doing on data source. Jinmei: In theory it might be possible, but I'm not sure if it is really realistic. To do that someone needs to have intensive research - for example - how exactly to handle some complicated protocol concept, and then provide a very detailed, broken-down, small tasks, so we can accurately estimate time. That itself will be a huge task. I'm not sure if it's really better than our current approach, which is using a relatively coarse-grained tasks and let the developers choose the details. Stephen: Two points:

With the exception of a couple of people, most of us are new to writing name servers. There is the risk that we make the same mistakes that, say, the authors of BIND 9 did when they wrote that feature. So we repeat the mistakes of the past instead of learning from them.

If you do have to do detailed breakdown of tasks, and don't do it, then everyone has to do that breakdown. So the effort is spread around many people.

Jelte: We tend to have one person write the tasks when normally the whole group does it, which may be impossible for us. Stephen: That's what I mean by writing a specification. Someone writing at a high level does not have the background knowledge of what was meant. Jinmei: I agree that we should learn from practice of the existing implementation. I recommend that in my reviews. In my opinion that is a different topic than how to design the tasks or task structures. It could be done by an individual developer when they work on a specific development task, for example by checking the behavior of the existing implementation or looking at the code. Michal: What I fear about doing the design beforehand is that it will be wrong. When someone picks up a small task, he says "we cannot do it this way" and the design from that point needs to be redone. [ Shane gives speech, blah blah blah ] Stephen: We're going from the model where everyone can take any task, rather than having expertise. In the second model, the expert can work without detail, because they know the code and have good mental models. If you expect anyone to be able to take a task, then you need to have a more complete description and put a lot more context. Jelte: I don't know what we can say except "try to do better". I'd like to move on... Jinmei: I have two points.

Regarding the number of people that estimate, I thought we talked about this at the face to face meeting. I thought we discussed the option of making a reminder at the daily call.

We should probably emphasize that people do not have to provide all of the estimates if they are not sure about that. (If that is correct.) Then we can hopefully expect more people, even if the answer is partial.

Jelte: I'll start doing the first, and we can all start doing the second. Review of Past Sprint - Technical --- Jelte: Added 3 tickets to clean up wrapper API. "Really small finishing tasks" is the approach here, rather than wait and block. Jinmei: I feel that this is inevitable and not so bad actually. Jelte: While doing #1179 I needed a lot of changes, so if I had discovered this today, then this would be a good time to discuss it. Shane: do we need to discuss the datasource config? Sprint Planning: Next sprint features and tasks --- IXFR-in developed now. What is needed for IXFRIN? Focus on SQLite (for now). Do we need to design differences? Stephen: We use our main database, and have a table containing differences in IXFR. Michal: We don't need it now from an API point of view. We don't need differences for IXFR-in. Michal: Switch to new data sources still does not have full DNSSEC support. Jelte: We can use what we have now, OR we can finish the factory function and use it as we will eventually use it. But we can get started on the protocol. Michal: If the SQLite preserves the database layout, we can do this in xfrin and then wait to switch until after we have implemented DNSSEC stuff. So we could start doing IXFR-in right now. Jelte: There will probably be 1 or 2 snags, but I think so. (One advantage of not having changed the schema!) Jelte: Dependency of switching XFR-in to the new API. Jinmei: If we are in a hurry we can even leave the AXFR part untouched, and use the new API only for IXFR. Jelte: I need to look at the code, but that might be possible. Jinmei: Maybe there are some configuration issues. Probably not. Stephen: Should we look at tasks? Jinmei: Also #1213: Stephen: Use the new API only for IXFR? Jinmei: Maybe we can converge both of them, without a large bottleneck. Decision 1: We do not do auth or xfrout conversion to new datasrc API. Shane: next question is whether to update xfrin or implement IXFR-in separately. Jinmei: I really don't know which one is better, even if our focus is just speed. In some sense it will be better even if we serialize these tasks. In term of number of tasks it is better if we only think of one task. Shane: about 900 lines of code in xfrin now. Michal: How many tests would we need to write if we re-used xfrin? Jelte: Is #1212 enough as a task, or do we need to split it up? Jinmei: I think we'll see some details and follow-up tasks. But at the moment we cannot be sure. Whoever takes this task first should not spend too much time, but should divide if it takes time. Michal: Could try experiment based on different time zones. Shane: Maybe we can try a design team? The first person to get the ticket pull in someone else. Jinmei: Someone starts reads RFC 1995 (it is pretty short) and looks at the existing implementation, then propose implementation of the tasks, in one day. If we need it have a separate call or something to organize that. Tasks to be carried forwards --- Jelte: Everything move forward, but set priorities. Michal: #1163? Stephen: Is the documentation for the refactoring tidied up? Michal: If someone is feeling really brave they can use the API documenation. Stephen: I think the key words are "if you are feeling really brave". That is not the level we want. Jelte: Put in next-sprint-proposed for following sprint. I do want to have this reasonably fast, since we are active in the API and know a lot about it. Jelte: Also ticket #833, which has been a pain for a long time now. Shane: It is important, but not as important as the functionality for the authoritative server right now. Shane suggests #1194, but Jinmei points out there is a workaround. Jeremy suggest #1205, since it is our goal for next release. Jelte suggests #1247, since it will help the development. (Jeremy will take.) Michal: #1205 should be easy if done in the minimal way. Jeremy: Might be nice to have documentation for how to add an RRType, since there have been mistakes. (No ticket yet.) Jelte suggests #1251, #1252, #1253. Minor tasks. Jeremy requests 5 defects that do not include the reviews. Shane: I'd rather have IXFR-in than fix bugs. Jinmei: I disagree. We always don't have time. We can easily find an excuse why we don't include bug fixes. In my opinion we should be very serious about including them. Even if we are in some emergency status. Jelte: As it happens, in the current sprint there are 3 unassigned defects. In the next-sprint-proposed there are 6, and I think 3 are quite easy. Jinmei: My suggestion is to include them as a compromise. Any other tasks ---

Last modified 7 years ago Last modified on Sep 27, 2011, 5:14:33 PM