Changes between Version 1 and Version 2 of WeeklyMinutes20100824

Aug 24, 2010, 5:18:25 PM (8 years ago)



  • WeeklyMinutes20100824

    v1 v2  
     1== Attendees ==
     18== Meeting next week ==
     20Shane gives rough overview. Agenda later today.
     22== Security Ticket ==
     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.
     26Shane: DVCS makes this go away?
     28Jelte: Slightly different problem. You still have the 0-day effect, as soon as you commit it.
     30Shane: There is procedure that needs to happen around this.
     34Shane: Are we ready for this, or do we have more requirements?
     36Larissa: I think we are close, maybe we can talk about next week. Should not be too different from other products.
     38Shane: Fundamentally different because code is public.
     40Larissa: Yes for that we need different, but a lot is the same. We may also have something our new security guy wants.
     42Larissa: I propose that I come up with a list of requirements both from open and existing repositories.
     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.
     48Jelte: Anyone with commit access.
     50Jinmei: I don't know if this is technically difficult, but right now it is inconvenient.
     52Shane: I don't have any problems.
     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.
     56Jeremy: I don't know if I agree with that. Someone might look at it and commit a fix without understanding it.
     58Michael: Someone might accidentally introduce a bug with any commit though...
     60Larissa: I think if we trust someone with commit access then we need to trust them with this.
     62Shane: It is slightly different because if a security bug gets out there then it's out there...
     64Michael: In the past we have had secret bug fixes.
     66Jelte: Especially because we don't want unreviewed code by definition.
     70Shane: Also don't know whether we want to change the policy when development is over, when we move to maintenance...
     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.
     78Jeremy: Will someone look at the patch?
     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.
     82Shane: Make it public?
     84Jeremy: I could add more people.
     86Shane: Either way I'm fine.
     88Jinmei: To be clear, the ticket is sensitive because it is a possible security issue.
     90Shane: I don't think the impact will be very great. Nobody should be running BIND 10 in production.
     92Jinmei: Then I'll make it public.
     94== Longer Review Time ==
     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.
     100Jelte mentions that we have the goal for the Linux model - short "merge window", long stabilization model
     104Shane: Any specific time lengths?
     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.
     108Jeremy: The goal is... we have a code freeze deadline and we don't have enough time to do the review for those.
     110Jelte: I agree... noting that you can still do other work, but review has priority.
     114Jeremy: Make sure we assign reviews continually, and not waiting until the last week.
     116Jinmei: That reminds me of the formal review assignment process. This does not work now.
     118Shane: I'm not sure how to fix it. I'll put on agenda for next week.
     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.
     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.
     126Michael: I'd push against that, as more reviews happen in that week. More time means more work to review.
     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.
     132Shane: I guess we can commit to the longer period for the next release.
     134== BIND 10 logging ==
     135Jeremy: This was an action point from the last meeting.
     139Jeremy: Is xfrout logging correct? Need to check that before we roll it out to all modules.
     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.
     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.
     147= Active Tickets from Previous Milestones =
     149Jeremy: Maybe we're trying to have too many goals per milestone, or maybe we're not understanding the resources available.
     151Larissa: Instead of assigning tickets ahead, maybe we can look at the whole pile at the beginning.
     153Jeremy: Our current milestones are not accurate to what they used to be. There are many, many tickets that were not completed.
     155Shane: In Scrum, nobody owns any tickets at the beginning of a sprint.
     157Michael: People only work on the tickets they are working on.
     159[ daily 15-minute stand-up call mentioned ]
     161= Date of 6 month release =
     163Shane: 2010-09-17, because the ISC all hands is 2010-09-20 to 2010-09-24
     165Jinmei: Face to face, vacation, other DNS trips, not available in September. Will send mail.
    15 Meeting next week
     168== Face to Face ==
     169Shane will have rough draft today
     171Michael: have not yet booked a car, but will do it today
     173Larissa: Will make a list and check with Bernie for rides.