wiki:WeeklyMinutes20110525

BIND 10 Conference Call

2011-05-25 @ 15:00 UTC

Attendees

Shane
vorner
Aharen
Jelte
Jeremy
Kambe
Larissa
Likun
Stephen
Jinmei
Keith
Jerry
Chao

Agenda

  • Sprint retrospectives
  • Release retrospective
  • Minor work into sprints: We need a way to get smallish work into our sprints, while still progressing towards our major goals
  • Face to Face meeting
  • practicing security fix development/patch releases (just happen to remember we discussed and planned this before and then forgot it as usual:-)
  • unassigned reviews: (IIRC) we've had several in the previous sprint, and still have two (#739 and #746) that haven't been taken for over a week. I'd suggest we recall review tasks should generally be considered higher priority ones (not to insist I'm the one who don't forget it:-)
  • Maybe just to remind (not that there would be anything to discuss), msgq is a beast.

Face to Face meeting

Conflict with meeting in Japan week after.

Conflict with Keith's agenda week before.

Keith's preference with original schedule.

Shane & Jeremy to discuss his attendance off call.

Sprint retrospectives

Retrospective vs. review

Retrospective is about the process (e.g. "things went well", "tasks were the right size", things like that). Format is typically "stop/start/continue".

Review is about the code. Whether it meets the criteria, and usually a demonstration in scrum.

Stephen does this at start of sprint planning. Organizational vs. technical, with specific questions for feedback.

Stephen: We are doing sprints every 2 weeks. Is there sufficient to have a proper review every 2 weeks. (Something more than "any comments?")

Jelte: I don't usually think about it until the call itself. Then it is too late to consider the retrospective.

Shane: Several items to consider for the sprint planning.

Stephen: Tickets depend on which features we want to address.

Shane: Should we have a reminder about upcoming sprint planning in jabber too?

Larissa: for retrospective maybe not thinking ahead, so jabber might be a good solution

Shane: One thing missing is demonstrations. Should we just pick people for demonstrations?

Stephen: We can, but are we talking about demonstrations to the customers or to developers?

Jeremy: As developers I think we need both. Not sure about sprint protocol. We also have an issue about time. One or two demonstrations could easily use up our entire time.

Stephen: We generally hit our time limit.

Larissa: Should we do a different time?

Stephen: Other way is to hold detailed retrospectives every 6 weeks.

Jelte: Not sure about that. I think the idea to do it very regularly is to prevent problems from escalating.

Jinmei: That is my understanding too.

Larissa: Maybe demonstration every 6 weeks.

Jelte: If we prepare for a potential demonstration, can we make those in a way that we can do "how to reproduce this demonstration"?

Larissa: If we did them in WebEx? we could record them.

Vorner: I have a hard time imagining how it would look like.

Larissa: Building an archive and making it viewable would be awesome.

Vorner: Then copy of a terminal may be enough.

Shane: Yeah, we could use the "script" program.

AP: Shane will have a look at this idea. Will post to bind10-dev.

Release retrospective

Jeremy: Too much new code introduced in previous 24 hours. Untested & undocumented. I hit around 6 issues when testing latest master.

  • incompatible configuration
  • TSIG key reuse

"make systest" will help with that.

Jeremy: Jinmei, Jelte, and Michal were available to fix and test issues at the last minute. We got lucky!

Jeremy: FTP server was down. I forgot about this since it had been 10 days. This caused delay to get files uploaded to the FTP server.

Jeremy: Forgot to send message to web-request.

Jeremy: Lots of little things added up to a very long day.

Jeremy: Not sure if it is on isc.org.

Jeremy: Before we did have a lot of lead time.

Shane: Should we have this call be the time for a release retrospective, like this?

Larissa: Yes.

Jinmei: Should we extend the meeting time, like a sprint planning? So we start 30 minutes earlier than usual?

Shane: I think it makes sense.

Michal: It will make sense to remember "when will we call"?

Jeremy: Because we did a release, we discovered a lot of problems.

Larissa: This is why it is important to do it.

Vorner: Still, we find problems not the customer or user. Maybe when we have enough users they will discover even more problems for us, so we will spend the first week of each 6-week cycle fixing their bugs.

Shane: Does it make sense to do a beta release or an alpha release?

Jinmei: I think it's too early.

Jeremy: All are beta releases basically.

Jelte: I think we should also move towards the hardening sprint as the last sprint of each release.

Stephen: After we came to the end of the sprint, how much additional work was there to get it to the point where you could release it?

Jelte: Probably a full day for Jinmei, Jelte, and Vorner.

Stephen: After we make a release, there is not enough work to make a hardening sprint. Maybe what we should be doing is issuing the release 1 week after the sprint comes to an end. Anything discovered gets put into the sprint as a work item.

Vorner: There is a lot of work for hardening sprint. The day of work for 3 people is emergency fixes.

Stephen: The argument then is if there is a week's worth of work then we should be able to schedule it in.

Jinmei: I don't think delaying the release is a good solution. It's more about a formal planning problem. We tried to do too much.

Shane: I think we were okay.

Jeremy: A lot of things on the sprint were not even looked at.

Stephen: We overcommit to make sure we don't run out of work.

Stephen: I think we need to run through a series of tests after we have the cut-off.

Shane: Don't want to duplicate the BIND 9 process.

Shane: Not sure about changing our release process.

Jinmei: I don't think it solves the problem.

Larissa: I think someone should write a proposal on how we should change it.

Jeremy: Just to point out again, these are only snapshots, and we have always released on time. We do have a plan for production releases, which go over a long time. We will have a branch where we will push fixes in for beta cycles.

Jeremy: Regardless of the amount of time we have between the end of a sprint and the beginning of a release, we hit issues using it in production. Having a documented checklist and automated tools will at least give us the list.

Jelte: It's not formal, but now that I'm actually running this I expect to run into problems earlier. I already found quite a few.

Jinmei: I personally normally check the latest master code a few days before release. So I can compile it and do some minimal tests. We should periodically check out and run the code on our own machines.

practicing security fix development/patch releases

just happen to remember we discussed and planned this before and then forgot it as usual:-)

Jeremy: Michael Graff had proposed a naming scheme that git push hooks could honor to make sure we don't accidentally put things into the public repo and don't send e-mails about it. The most important thing was having a checklist that we follow.

Jeremy: In the past couple sprints there was a ticket for a security issue. Very minor, but something we could have used to start developing our checklist. Ticket #870

AP: Jeremy, Larissa, Shane - draft security fix checklist

unassigned reviews

(IIRC) we've had several in the previous sprint, and still have two (#739 and #746) that haven't been taken for over a week. I'd suggest we recall review tasks should generally be considered higher priority ones (not to insist I'm the one who don't forget it:-)

Jinmei: Just a "head's up". It would be nice if everyone first looks at the review queue before doing anything new. Especially after finishing another development work, so we can constantly clean up the open review list.

Jelte: It had grown, but it was a good reminder.

Jeremy: Can we have a specific rule, that you have to grab a review.

Shane: We kind of already have that rule.

Vorner: Problem is that if I take some task and it takes a longer time, then I don't check the review tickets in between. I first look into my tickets. So sometimes it takes 2 or 3 days.

Jelte: That's not a problem. If you need something reviewed fast, you need to ask people directly.

msgq is a beast

Maybe just to remind (not that there would be anything to discuss), msgq is a beast.

Stephen: Did have a task to look at alternatives.

Vorner: Spent 2 days last week debugging it.

Shane: I think we have 2 more alternatives to investigate. We can think about putting on the next sprint.

Jeremy: Should we ask people outside of the BIND 10 team. Ask outsiders on the bind10-dev list?

Vorner: I don't think anyone will do that. They don't really want to help or something. Usually people want to make it do what they want, then if it works for them they'll send a patch.

Jeremy: Not to code it, but simply let them know. They might point us to something we did not know about.

AP: Shane to ask bind10-dev list for help.

Minor work into sprints

We need a way to get smallish work into our sprints, while still progressing towards our major goals

Shane: We have a lot of really small tasks - like less than a half hour total.

Jinmei: I think we underestimate the work of doing a small task, including the process of reviewing. I don't think it's a good idea to push them to the current sprint randomly. Maybe like bug fixes, we can have a set of small things every sprint.

Stephen: That's what I was going to suggest. Lets schedule them in too. I don't think we should add things to the sprint unplanned.

A.O.B.

Jeremy: I want to propose if we have configuration or useage changes that we discuss ahead of time. In the long run it's getting really disjointed.

Shane: If we have not discussed by next call I'll put it on that call.

Jeremy: We have a few different environment variables that various daemons honor. But these are based on source tree or various things. I want to make these abstracted so we set them with more generic names. Some of them are not honored if others are defined, so I want to change ordering. I'll send an e-mail.

Last modified 6 years ago Last modified on May 25, 2011, 12:36:01 PM