wiki:WeeklyMinutes20100824

Attendees

Jinmei
Evan
Jerry
Stephen
Jelte
Larissa
Kambe
Hankins
Shane
Jeremy
Fujiwara
Michael

Meeting next week

Shane gives rough overview. Agenda later today.

Security Ticket

Jinmei: 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.

Shane: DVCS makes this go away?

Jelte: Slightly different problem. You still have the 0-day effect, as soon as you commit it.

Shane: There is procedure that needs to happen around this.


Shane: Are we ready for this, or do we have more requirements?

Larissa: I think we are close, maybe we can talk about next week. Should not be too different from other products.

Shane: Fundamentally different because code is public.

Larissa: Yes for that we need different, but a lot is the same. We may also have something our new security guy wants.

Larissa: I propose that I come up with a list of requirements both from open and existing repositories.


Jinmei: 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.

Jelte: Anyone with commit access.

Jinmei: I don't know if this is technically difficult, but right now it is inconvenient.

Shane: I don't have any problems.

Jelte: 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.

Jeremy: I don't know if I agree with that. Someone might look at it and commit a fix without understanding it.

Michael: Someone might accidentally introduce a bug with any commit though...

Larissa: I think if we trust someone with commit access then we need to trust them with this.

Shane: It is slightly different because if a security bug gets out there then it's out there...

Michael: In the past we have had secret bug fixes.

Jelte: Especially because we don't want unreviewed code by definition.


Shane: Also don't know whether we want to change the policy when development is over, when we move to maintenance...


Jeremy: Another thing, you may not notice that it is flagged "Sensitive", it's not very noticeable. It's a tiny checkbox, easy to overlook.


Jeremy: Will someone look at the patch?

Jinmei: 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.

Shane: Make it public?

Jeremy: I could add more people.

Shane: Either way I'm fine.

Jinmei: To be clear, the ticket is sensitive because it is a possible security issue.

Shane: I don't think the impact will be very great. Nobody should be running BIND 10 in production.

Jinmei: Then I'll make it public.

Longer Review Time

Jeremy: 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.


Jelte mentions that we have the goal for the Linux model - short "merge window", long stabilization model


Shane: Any specific time lengths?

Jeremy: 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.

Jeremy: The goal is... we have a code freeze deadline and we don't have enough time to do the review for those.

Jelte: I agree... noting that you can still do other work, but review has priority.


Jeremy: Make sure we assign reviews continually, and not waiting until the last week.

Jinmei: That reminds me of the formal review assignment process. This does not work now.

Shane: I'm not sure how to fix it. I'll put on agenda for next week.

Jinmei: 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.


Jinmei: 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.

Michael: I'd push against that, as more reviews happen in that week. More time means more work to review.

Jinmei: 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.


Shane: I guess we can commit to the longer period for the next release.

BIND 10 logging

Jeremy: This was an action point from the last meeting.

http://bind10.isc.org/wiki/Bind9Logging

Jeremy: Is xfrout logging correct? Need to check that before we roll it out to all modules.

Michael: 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.


Michael: 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.

Active Tickets from Previous Milestones

Jeremy: Maybe we're trying to have too many goals per milestone, or maybe we're not understanding the resources available.

Larissa: Instead of assigning tickets ahead, maybe we can look at the whole pile at the beginning.

Jeremy: Our current milestones are not accurate to what they used to be. There are many, many tickets that were not completed.

Shane: In Scrum, nobody owns any tickets at the beginning of a sprint.

Michael: People only work on the tickets they are working on.

[ daily 15-minute stand-up call mentioned ]

Date of 6 month release

Shane: 2010-09-17, because the ISC all hands is 2010-09-20 to 2010-09-24

Jinmei: Face to face, vacation, other DNS trips, not available in September. Will send mail.

Face to Face

Shane will have rough draft today

Michael: have not yet booked a car, but will do it today

Larissa: Will make a list and check with Bernie for rides.

Last modified 7 years ago Last modified on Aug 24, 2010, 5:18:25 PM