Changes between Version 1 and Version 2 of WeeklyMinutes20100824


Ignore:
Timestamp:
Aug 24, 2010, 5:18:25 PM (7 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WeeklyMinutes20100824

    v1 v2  
     1== Attendees ==
     2
     3{{{
    14Jinmei
    25Evan
     
    1114Fujiwara
    1215Michael
     16}}}
     17
     18== Meeting next week ==
     19
     20Shane gives rough overview. Agenda later today.
     21
     22== Security Ticket ==
     23
     24Jinmei: Don't need to repeat the problem itself. We need to discuss how in general to handle these kinds of things. In particular, how we can co-ordinate review if we open the repository.
     25
     26Shane: DVCS makes this go away?
     27
     28Jelte: Slightly different problem. You still have the 0-day effect, as soon as you commit it.
     29
     30Shane: There is procedure that needs to happen around this.
     31
     32----
     33
     34Shane: Are we ready for this, or do we have more requirements?
     35
     36Larissa: I think we are close, maybe we can talk about next week. Should not be too different from other products.
     37
     38Shane: Fundamentally different because code is public.
     39
     40Larissa: Yes for that we need different, but a lot is the same. We may also have something our new security guy wants.
     41
     42Larissa: I propose that I come up with a list of requirements both from open and existing repositories.
     43
     44----
     45
     46Jinmei: Related issue is viewing sensitive ticket. Right now only a few people can see sensitive tickets. This is why, according to Jeremy, we cannot open these reviews to anyone. Basically I think it should be open to the main developers.
     47
     48Jelte: Anyone with commit access.
     49
     50Jinmei: I don't know if this is technically difficult, but right now it is inconvenient.
     51
     52Shane: I don't have any problems.
     53
     54Jelte: In the end that is part of the policy we have. For now I suggest anyone who can commit should be able to look at sensitive tickets.
     55
     56Jeremy: I don't know if I agree with that. Someone might look at it and commit a fix without understanding it.
     57
     58Michael: Someone might accidentally introduce a bug with any commit though...
     59
     60Larissa: I think if we trust someone with commit access then we need to trust them with this.
     61
     62Shane: It is slightly different because if a security bug gets out there then it's out there...
     63
     64Michael: In the past we have had secret bug fixes.
     65
     66Jelte: Especially because we don't want unreviewed code by definition.
     67
     68----
     69
     70Shane: Also don't know whether we want to change the policy when development is over, when we move to maintenance...
     71
     72----
     73
     74Jeremy: Another thing, you may not notice that it is flagged "Sensitive", it's not very noticeable. It's a tiny checkbox, easy to overlook.
     75
     76----
     77
     78Jeremy: Will someone look at the patch?
     79
     80Jinmei: This is minor and we have a workaround to avoid the attack. We can wait, but it doesn't make much sense to defer the review and integration just for the procedure.
     81
     82Shane: Make it public?
     83
     84Jeremy: I could add more people.
     85
     86Shane: Either way I'm fine.
     87
     88Jinmei: To be clear, the ticket is sensitive because it is a possible security issue.
     89
     90Shane: I don't think the impact will be very great. Nobody should be running BIND 10 in production.
     91
     92Jinmei: Then I'll make it public.
     93
     94== Longer Review Time ==
     95
     96Jeremy: For the last 2 releases, we did a code freeze on the Friday before, but that was only a couple of working days. We should have more days dedicated for review only. I am proposing we have the new code freeze done earlier so we have at least 5 days for review-only work. It seemed really successful having those 2 days dedicated for review only, but there wasn't enough time.
     97
     98----
     99
     100Jelte mentions that we have the goal for the Linux model - short "merge window", long stabilization model
     101
     102----
     103
     104Shane: Any specific time lengths?
     105
     106Jeremy: If we have a release date on a Wednesday, a code freeze would be the Monday a week before, so then Monday through Monday would be reviews and coding related to feedback on reviews, with a final commit freeze on the Tuesday.
     107
     108Jeremy: The goal is... we have a code freeze deadline and we don't have enough time to do the review for those.
     109
     110Jelte: I agree... noting that you can still do other work, but review has priority.
     111
     112----
     113
     114Jeremy: Make sure we assign reviews continually, and not waiting until the last week.
     115
     116Jinmei: That reminds me of the formal review assignment process. This does not work now.
     117
     118Shane: I'm not sure how to fix it. I'll put on agenda for next week.
     119
     120Jinmei: What we are doing works pretty well. We ask for the seemingly best reviewer directly. It's just different from the stated formal assignment process.
     121
     122----
     123
     124Jinmei: Assuming we have 6 week periods for the release cycle I think the longer review period is okay. If we have 4 weeks, maybe it is too long. I agree with the concept, but I think we should have a relatively longer development cycle.
     125
     126Michael: I'd push against that, as more reviews happen in that week. More time means more work to review.
     127
     128Jinmei: I understand the generic point. My concern is about the specific numbers, whether it is 3 of 4 or 5 of 6. The latter makes sense but the former seems to be unworkable.
     129
     130----
     131
     132Shane: I guess we can commit to the longer period for the next release.
     133
     134== BIND 10 logging ==
     135Jeremy: This was an action point from the last meeting.
     136
     137http://bind10.isc.org/wiki/Bind9Logging
     138
     139Jeremy: Is xfrout logging correct? Need to check that before we roll it out to all modules.
     140
     141Michael: Doesn't matter what we want. We'll do what we are told. I know that Paul is very upset that BIND 9 does not do *exactly* what BIND 8 does. I have a feeling we won't have a lot of choice in the matter.
     142
     143----
     144
     145Michael: Maybe instead of figuring out what BIND 9 does figure out why people use it. This is the crux of my argument that we cannot be BIND 9 compatible. That means we have to have the same code and the same bugs, which is kind of pointless.
     146
     147= Active Tickets from Previous Milestones =
     148
     149Jeremy: Maybe we're trying to have too many goals per milestone, or maybe we're not understanding the resources available.
     150
     151Larissa: Instead of assigning tickets ahead, maybe we can look at the whole pile at the beginning.
     152
     153Jeremy: Our current milestones are not accurate to what they used to be. There are many, many tickets that were not completed.
     154
     155Shane: In Scrum, nobody owns any tickets at the beginning of a sprint.
     156
     157Michael: People only work on the tickets they are working on.
     158
     159[ daily 15-minute stand-up call mentioned ]
     160
     161= Date of 6 month release =
     162
     163Shane: 2010-09-17, because the ISC all hands is 2010-09-20 to 2010-09-24
     164
     165Jinmei: Face to face, vacation, other DNS trips, not available in September. Will send mail.
    13166
    14167
    15 Meeting next week
     168== Face to Face ==
     169Shane will have rough draft today
    16170
     171Michael: have not yet booked a car, but will do it today
    17172
    18 
     173Larissa: Will make a list and check with Bernie for rides.