Changes between Initial Version and Version 1 of SprintPlanning20110628


Ignore:
Timestamp:
Jun 29, 2011, 11:01:01 AM (6 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SprintPlanning20110628

    v1 v1  
     1= BIND10 Sprint Planning Meeting - 28 June 2011 =
     2
     3== Present ==
     4{{{
     5Shane
     6Stephen
     7Aharen
     8Likun
     9Ocean
     10Jenny
     11Jeremy
     12Larissa
     13Michal
     14Jelte
     15Kambe
     16Fujiwara
     17Jinmei
     18}}}
     19
     20== Review of past Sprint - organisational ==
     21* Selection of tasks for sprint
     22  Do we "slack off" as we get to the end of a sprint?
     23
     24* Other comments
     25
     26Jeremy: 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.
     27
     28Michal: 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.
     29
     30Shane: There are Trac plugins which document inter-ticket dependencies. Has not been a high priority.
     31
     32Stephen: 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?".
     33
     34We 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.
     35
     36Michal: 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.
     37
     38Stephen: 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?
     39
     40Michal: 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.
     41
     42Jeremy: 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.
     43
     44Michal: Yeah, there is no user documentation right now.
     45
     46Stephen: Do we think that this is a problem? Lack of oversight for the progress of a feature?
     47
     48Jelte: Well, for Jeremy it is! In his function as a release engineer. So I would say "yes".
     49
     50Jeremy: 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.
     51
     52Jinmei: What kind of oversight are we talking about?
     53
     54Stephen: 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.
     55
     56Jinmei: 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.
     57
     58Stephen: We have compromised agile anyway... it is designed for small teams working closely together in one room. We are separated around the planet.
     59
     60Jinmei: 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.
     61
     62Jelte: Keeping an eye whether the task becomes the user visible feature is the role of the scrum master, right?
     63
     64Stephen: The scrum master facilitates scrum.
     65
     66Michal: I have seen other !Trac/Bugzilla sites do... meta-tickets. All this discussion is done on the meta-ticket. Would it make sense?
     67
     68Shane: Maybe we need to look at the problem (missing stuff) rather than solutions?
     69
     70Stephen: On our mid-sprint call, maybe we need to put sprint progress on the agenda?
     71
     72Larissa: I think that would help. I am also not opposed to the meta-ticket that Michal proposed.
     73
     74Stephen: Okay lets try that.
     75
     76----
     77
     78Jeremy: 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.
     79
     80Larissa: It is common in Scrum to put "conditions of completeness" into the ticket.
     81
     82Stephen: 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.
     83
     84Larissa: Maybe this is something that I need to work on... I'm not sure how to solve this.
     85
     86Shane: Perhaps writing tickets as user stories would help.
     87
     88Larissa: Not sure if we want to do it before the next face to face?
     89
     90Stephen: 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". ;)
     91
     92Larissa: User stories may be more useful for requirements.
     93
     94----
     95
     96Jinmei: 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.
     97
     98Jinmei: As long as this is a moderate problem perhaps we can accept that for now.
     99
     100Stephen: I can try to ask people about that.
     101
     102Shane: We have daily calls for this.
     103
     104Michal: I did raise that issue (on Jabber)...
     105
     106Stephen: And I was ashamed enough that I reviewed them right away!
     107
     108Jelte: 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!
     109
     110== Review of past Sprint - technical==
     111The goals of the sprint were:
     112
     113    * Finish Logging
     114    * Implement ACLs on the Resolver
     115
     116'''Finish Logging'''
     117
     118Stephen: 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.
     119
     120Jeremy: The new logging introduced a serious regression in performance.
     121
     122Stephen: 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...
     123
     124Jeremy: I think I created a ticket. If not, then I will do that this afternoon.
     125
     126Stephen: To be looked at as some matter of urgency.
     127
     128Stephen: If debugging is enabled then it makes sense. If not, then the basic check is very, very slow.
     129
     130'''Implement ACLs on the Resolver'''
     131
     132Michal: 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.
     133
     134Shane: TSIG support?
     135
     136Michal: No.
     137
     138Jinmei: 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.
     139
     140== Sprint Planning ==
     141(from Shane's email of https://lists.isc.org/pipermail/bind10-dev/2011-June/002410.html):
     142
     143Shane: We have additional work from the release. This would only give us 2 sprints for the next release. What to do?
     144
     145Stephen: 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.
     146
     147Larissa: We have a big plan, but if we convey the message then I don't think it is a problem.
     148
     149Shane: And above all we have to be realistic.
     150
     151Jinmei: 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++.
     152
     153Shane: You mean a large set of smallish tasks?
     154
     155Jinmei: Yeah.
     156
     157Michal: The logging conversion are not that small. But they are small and can be done any time.
     158
     159Jelte: 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.
     160
     161Stephen: In part because you are writing the documentation as well.
     162
     163----
     164
     165Stephen: Design tasks?
     166
     167Michal: Have we decided about the msgq?
     168
     169Shane: No.
     170
     171Larissa: That may be appropriate for here.
     172
     173Shane: Also... writing data sources. Is there overlap?
     174
     175Michal: Hard to design if the code does not exist.
     176
     177Jinmei: 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.
     178
     179Shane: Hard deadline of next sprint for decision. Was posted 3 weeks ago.
     180
     181https://lists.isc.org/pipermail/bind10-dev/2011-June/002314.html
     182
     183Shane: Also how we implement multiple core support.
     184
     185Michal: I think we need more discussion rather than design.
     186
     187Stephen: I think we need the proposal written down, so we can comment on it.
     188
     189Michal: Shall I dig up the discussion?
     190
     191We're going to be starting work on the next release next week. Most of
     192the work on this will by necessity be groundwork for the *following*
     193release, I think. It doesn't seem likely we can add DDNS/IXFR in a
     1946-week period, if we're going to do it right.
     195
     196Here's what's in Wiki now:
     197
     198      * DDNS
     199              * New model for writing to data sources
     200      * IXFR-out
     201              * New model for writing to data sources
     202      * IXFR-in
     203              * New model for writing to data sources
     204      * High-performance data source
     205              * Refactor of data sources
     206              * Profiling of refactored data sources
     207              * Performance improvements to existing data source done
     208              * Update NSD-inspired prototype to match refactored code
     209      * msgq replacement
     210      * All RRTYPE codes implemented
     211      * Socket creator completed
     212      * b10-auth use multiple cores
     213      * Equivalent of "rndc reload" and other such commands for
     214        in-memory data source(s)
     215
     216'''Goals for the new sprint'''
     217
     218Stephen: Summary. For the short term:
     219
     220 * Finish logging
     221 * Finish ACLs
     222 * Bugfixing
     223 * Design
     224
     225'''What tasks do we carry forwards?'''
     226
     227All of them.
     228
     229'''What tasks do we add?'''
     230
     231'''Tidying up Next-Sprint-Proposed'''
     232
     233Jeremy: I had an e-mail with like 18 issues about logging. I think that would turn into 5 or more tickets.
     234
     235Stephen: I'll turn those into tickets to be added to the sprint.
     236
     237#693 Solved (possibly) [[BR]]
     238#712 [[BR]]
     239#714 [[BR]]
     240#768 [[BR]]
     241#910 [[BR]]
     242#926 (only if found to be needed later on) [[BR]]
     243#981 [[BR]]
     244#983 [[BR]]
     245#988 Solved (possibly) [[BR]]
     246#994 [[BR]]
     247#1006 Solved (possibly) [[BR]]
     248#1009 Done (possibly) [[BR]]
     249#1016 [[BR]]
     250#1024 [[BR]]
     251#1025 [[BR]]
     252#1029 [[BR]]
     253#1053 [[BR]]
     254#1069 [[BR]]
     255
     256We also need tasks for xfrin/xfrout ACL checks.
     257
     258#772
     259
     260Jinmei: we should sort tasks by priority
     261
     262+ticket about logging that affected Jeremy & Jinmei (I don't know what this means)
     263
     264Any Other Business
     265
     266Jeremy: Branching for the release in 2 days, then preparing for this next week.